Comunicazione dati astratta in design modulare

0

Sto facendo l'analisi per un software che avevo in mente da molto tempo. Il suo scopo è trasformare il suono in un'immagine, applicare trasformazioni grafiche su di esso e trasformarlo in suono per ascoltare il risultato. Ho intenzione di scriverlo in C ++ e voglio renderlo il più modulare possibile. Essendo relativamente inesperto nel design modulare, il mio approccio al problema potrebbe essere ingenuo.

L'app sarebbe un assembly di diversi Modules che hanno DataInputs e DataOutputs che potrebbero essere connessi l'un l'altro. Fondamentalmente, quando un modulo ha alcuni dati da inviare, può dire a uno dei suoi output di inviare un DataBlock a tutti gli input a cui è connesso, e questi input memorizzano il blocco di dati fino a quando il loro modulo non gli dice di leggere per ulteriore elaborazione. Questo produce il seguente diagramma di classe (estratto):

Lapartedicuinonsonoveramentesicuroèqualetipodovrebberoprendereidatiinterni(DataBlock::data).Finoadorahoinseritovoid*cometipoperchémiavrebbepermessodiriportarlostaticamenteinqualsiasicosaiovolessichefossesenzatroppiproblemi,mapermolteragionichenonhointenzionedienumerarequi,questoèovviamentenonèunasoluzioneconcuivoglioandare.UnasoluzionechemièvenutainmenteèdicreareuntipoBaseDataastrattodacuierediterebbequalsiasitipodidaticoncreto,inquestomodo:

Pensochequestasarebbeunasoluzioneokay,masonopreoccupatodiusarel'ereditarietà"solo" per far sì che i tipi di dati concreti abbiano qualcosa in comune mentre rappresentano cose completamente diverse. Con questa soluzione, i moduli dovrebbero gestire i blocchi di dati in modo diverso in base al loro tipo (dato dal campo DataBlock::dataType ), che a mio avviso va bene se eseguito correttamente.

Che valore ha questo design? Sono diretto nella giusta direzione o subirò il dolore di mille dei caduti a causa di qualche difetto che ho trascurato? Quali sono le potenziali alternative e / o modelli di design ben noti a tale scopo?

    
posta qreon 10.07.2018 - 14:22
fonte

1 risposta

1

Una classe base ha senso, se e solo se, puoi facilmente immaginare di eseguire operazioni su cose del tipo della classe base. Nel tuo esempio sopra (fino al punto in cui si è sviluppato) - sembra che questo non sia il caso.

Se stavo progettando qualcosa di simile a quanto sopra, vorrei che ogni modulo definisse qualunque API avesse senso per esso, e non sentivo il bisogno di farli avere input e output che potessero essere manipolati genericamente. Penso che questo sia il punto cruciale del problema che hai creato artificialmente per te.

Se - tuttavia - hai buone ragioni per voler trattare questi tre tipi di oggetti in modo generico, ci sono due famiglie di buoni modi per farlo in C ++.

  • modelli
  • unione delle varianti (unione con tag)

Modelli

Puoi scrivere algoritmi (procedure) che operano su un arbitrario 'typename T', e produrre qualunque tipo di output abbia senso.

UNIONE VARIANTE Per usare un sindacato variante (vedi link ) ci sono un certo numero di librerie o funzioni linguistiche che puoi usare. Tuttavia, probabilmente l'approccio meno debole sarebbe

- https://en.cppreference.com/w/cpp/utility/variant
  I'm not too fond of this approach, as its syntactically quite ugly.
    
risposta data 17.07.2018 - 01:17
fonte

Leggi altre domande sui tag