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:
-
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)?
-
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à?
-
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?