Scelte progettuali generali. Come decidi?

2

Ho un progetto in C che sto cercando di convertire in C ++. Il progetto esegue test dell'hardware della scatola bianca di un dispositivo (in realtà molti dispositivi simili). In questo caso il dispositivo ha due processori. Ognuno di essi ha capacità uniche ed entrambi hanno alcune caratteristiche simili (io e discreto). Il codice di test di livello superiore è una raccolta di funzioni esportate da una DLL.

Guardando il codice sapendo che dovrò supportare varianti aggiuntive dei dispositivi ho le seguenti domande che mi hanno fatto pensare che altri avrebbero suggerimenti sull'architettura / design e il ragionamento che sta dietro queste scelte di design aiuterà gli altri:

  1. Supporta una classe di dispositivi con membri proc_a e proc_b (ha un pensiero) con l'interfaccia con nomi di funzioni distinti, quindi è chiaro all'utente cosa viene manipolato o preferisce che l'interfaccia abbia uno schema di denominazione più generico ( come setDiscrete che prende un enume che comprende entrambi i processori 'discreti a (DISCRETE_PROC_A_x e _B_x)?

  2. Sapendo che le future varianti del dispositivo avranno processori aggiornati, come faccio a mantenere le modifiche solo a quelle funzioni che sono cambiate? Cioè Un nuovo processore B aggiunge funzionalità e i file di inclusione per quella funzionalità (dalla sorgente incorporata) sono diversi da ciò che viene utilizzato fino a quel momento. Sto pensando di rendere il processore una classe e non un figlio per gestire questa preoccupazione. Esiste un design più maneggevole? Cosa succede se l'interfaccia per quella classe deve cambiare, ma è necessaria la stessa funzionalità?

  3. Tell non chiedere è ottimo ma quando hai bisogno di setter o getter preferisci impostare / ottenere, spingere / tirare, impostare / cancellare, ecc.? Riesci a comunicare con il dispositivo e a memorizzare lo stato della tua classe? In tal caso, è una funzione di recupero separata e si utilizza una variabile di tracciamento dello stato o un'altra funzione nell'interfaccia?

posta Grasshopper 03.02.2015 - 03:12
fonte

1 risposta

1

Osservando le tue domande dirette, risponderò all'intera domanda con un singolo link ai Pattern Design di GoF -

link

E richiamo due schemi che ho usato ripetutamente durante la progettazione di software estensibile con riscrittura minima e cioè quello del Decorator Pattern - link e il modello di strategia - link

Per comprendere appieno le risposte dirette alle domande che poni, la comprensione dei modelli sopra ti aiuterà a informare il seguente pensiero.

  1. Puoi progettare la tua interfaccia per essere più generica, costruire la funzionalità di base condivisa dai dispositivi in un'implementazione concreta e quindi decorare le funzionalità aggiuntive sui comportamenti discreti che non sono condivisi.
  2. Effettuando quanto sopra, si limitano le modifiche solo alla nuova funzionalità. Se trovi che la tua interfaccia deve cambiare, probabilmente significa che la tua interfaccia non è stata progettata correttamente nel tuo primo caso d'uso. Anche la strategia può entrare in gioco, se hai bisogno di due processori per fare funzionalmente le stesse cose, ma su diversi tipi di input.
  3. La risposta a questo dipende da come hai deciso le implementazioni di cui sopra, per quanto riguarda la condivisione dei dati, la strategia e come hai fatto la decorazione. A seconda di cosa è necessario condividere, potresti utilizzare il modello Flyweight - link

Indipendentemente da ciò che decidi, spero che questo porti a casa l'importanza del design quando lavori con codice nuovo e vecchio per quanto riguarda il software riutilizzabile ed estensibile. L'a è, ha una sottoclasse genitore / figlio ha causato grandi difficoltà quando mal progettato!

Modelli felici!

    
risposta data 06.08.2015 - 06:22
fonte

Leggi altre domande sui tag