Per i miei requisiti di progettazione, questa gerarchia di progettazione sembra ragionevole?

Sfondo

Costruzione

Si noti che sto usando C # qui, ma potrebbe non essere necessario fornire input alle mie domande concettuali sul design. Considera la seguente metodologia di progettazione ...

Lavoro in un luogo in cui abbiamo diverse versioni di un determinato prodotto. Recentemente mi è stata data una specifica di progettazione per 3 delle versioni, in cui la specifica afferma che le 3 versioni sono identiche tranne che ognuna ha un nome diverso. Mentre mi è stata data una specifica solo per le 3 versioni, ci sono in realtà più di appena 3. Ho bisogno di iniziare a scrivere un oggetto di classe base secondo le specifiche di progettazione. Per il gusto di questa domanda, farò riferimento alla classe base di questo prodotto come ProductObject .

Inoltre, ogni ProductObject contiene 16 oggetti ai quali mi riferirò come EntryObject . Ognuno dei 16% diEntryObject (s) avrà bisogno di campi membri leggermente diversi, ma sono più o meno liberamente basati sulla stessa cosa.

Uso

La versione appropriata di ProductObject sarà costruita con una stringa di byte separati "a doppio spazio", a cui mi riferirò come SeparatedBytes . SeparatedBytes avrà sempre lo stesso formato, un'intestazione seguita dalla stringa di byte. Indipendentemente dal numero di versioni diverse di ProductObject , l'% in arrivo di co_de sarà sempre identico tranne che con carichi utili variabili. I payload sono solo letture del sensore e non hanno nulla a che fare con il modo in cui i dati appaiono in termini di formato (sembreranno sempre una stringa di byte separati da un doppio spazio). Ecco come appare SeparatedBytes :

01  EF  AB  02  ...  XX

Questa stringa di byte separati "double-space" verrà analizzata / divisa e passata al rispettivo SeparatedBytes . Ciascuno del 16% diEntryObjects (s) sarà costruito come una parola 32-bit del valore EntryObject . Quindi la costruzione di SeparatedBytes dovrebbe essere simile a:

EntryObject myEntryObject = new EntryObject("01EFAB02");

I primi 4 byte saranno il primo tipo di EntryObject , i secondi 4 byte saranno il secondo tipo di EntryObject , i terzi 4 byte saranno il terzo tipo di EntryObject , fino al sedicesimo tipo di EntryObject . Questo assomiglierà a qualcosa ...

EntryObjectType1 type1 = new EntryObjectType1("12345678");
EntryObjectType2 type2 = new EntryObjectType2(the next four bytes);
EntryObjectType3 type3 = new EntryObjectType3(the next four bytes);

.
.
.

EntryObjectType16 type16 = new EntryObjectType16(the final four bytes);

Gerarchia di progetto / ereditarietà proposta

Ho intenzione di affrontare il mio progetto nel modo seguente, con uno spazio dei nomi composto da quanto segue:

1. Avere una classe base per EntryObject .
2. Costruisci 3 classi figlio per ognuna delle versioni ProductObject .
3. Avere una classe base per ProductObject .
4. Hanno 16 classi figlio derivate dalla classe base EntryObject .
5. Hanno 16 membri EntryObject pubblici all'interno della EntryObject base-class.

Domande / Concern

La mia preoccupazione è principalmente con # 5 qui. Mi interessa il n. 5 perché mi sono state fornite solo le prime 3 versioni di ProductObject con cui lavorare.

Che succede se in fondo alla strada arriva una nuova versione di ProductObject e il ProductObject (s) all'interno si comporta diversamente? Sarà essere in grado di accogliere correttamente un tale cambiamento, data la mia gerarchia di progettazione proposta?