Per my design requirements, does this design hierarchy seem reasonable?

Question

Background

Construction

Note that I am using C# here, but it may not be necessary to provide input to my conceptual questions about design. Consider the following design methodology...

I work at a place where we have a number of different versions of a particular product. Recently I was given a design specification for 3 of the versions, wherein the specification states that the 3 versions are identical except that each has a different name. While I was only given a specification for the 3 versions, there are actually more than just 3. I need to begin writing a base-class object per the design specification. For the sake of this question, I will refer to the base class of this product as ProductObject.

Additionally, each ProductObject contains 16 objects which for the sake of this question I will refer to as EntryObject. Each of the 16 EntryObject(s) will need slightly different member fields, but are more or less loosely based on the same thing.

Usage

The appropriate version of ProductObject will be constructed with a string of "double-space" separated bytes, which I will refer to as SeparatedBytes. SeparatedBytes will always have the same format, a header followed by the string of bytes. No matter how many different versions of ProductObject, the incoming SeparatedBytes will always be identical except with varying payloads. The payloads are just sensor readings and do not have anything to do with how the data actually looks in terms of format (will always look like a string of bytes separated by a double-space). Here is how SeparatedBytes looks:

01  EF  AB  02  ...  XX

This string of "double-space" separated bytes will be parsed/split and passed on to their respective EntryObjects. Each of the 16 EntryObject(s) will be constructed as one 32-bit word worth of the SeparatedBytes. So construction of EntryObject should look like:

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

The first 4 bytes will be the first type of EntryObject, the second 4 bytes will be the second type of EntryObject, the third 4 bytes will be the third type of EntryObject, up until the sixteenth type of EntryObject. This will look something like...

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);

Proposed Design/Inheritance Hierarchy

I plan on tackling my design in the following manner, in having a namespace consisting of the following:

1. Have a base-class for the ProductObject.
2. Construct 3 child-classes for each of the ProductObject versions.
3. Have a base-class for the EntryObject.
4. Have 16 derived child-classes from the EntryObject base class.
5. Have 16 public EntryObject members within the ProductObject base-class.

Questions/Concern

My concern is mainly with #5 here. I am concerned with #5 because I was only given the first 3 versions of ProductObject to work with.

What if, down the road a new version of ProductObject comes along and the EntryObject(s) within, behave differently? Will I be able to accomodate such a change properly, given my proposed design hierarchy?

Answer 1

Applying OO at the bottom of the design facilitates future change everywhere

Unless you have some idea of how ProductObject may change designing for all change is nonsense. Nonetheless OO and its principles get us more than half way there in any case. But you must use OO "all the way down" but you have not.

Define a SeparatedBytes class

new EntryObject("01EFAB02"); should not be receiving a string but a SeparatedBytes object, or property, or method call, thereof.

Once you fill out that class with the appropriate properties and functionality you are giving clients an API to work with, not that stupid (a technical term in this case) string. And this means all the string handling that currently is going on in the existing higher-level classes goes away. Thus you have facilitated future change through the entire class hierarchy.

Define classes "all the way down"

The sub-parts of SeparatedBytes probably should be classes as well. The fact that 4 bytes defines a type is screaming to become a class IMHO. If you have to "break off" a 4-byte piece and pass it to another object, it better have some functionality that client can work with.

... all the way!

If there is any "special handling" done at the byte + double-space level then maybe there is a class here too. Anything that this structure can do for itself that can be encapsulated, expressed in business-speak, or simplified for client use.

---

My concern is mainly with #5 here. I am concerned with #5 because I was only given the first 3 versions of ProductObject to work with.

Now I think I can address this question.

The type of those 4 bytes will be encapsulated in some way within the SeparatedBytes structure. This "type definition/declaration" can be contained in the EntityObject class and now we can have something like a ProductObject.EntityObjectCollection of List<EntityObject> - general/generic objects that expose their "type" through the SeparatedBytes structure.

Answer 2

If you want to future proof it to allow for different configurations of EntryObjects, one option would be to have the base ProductObject class have a generic EntryObject collection, like List<EntryObject> or another kind depending on your requirements, instead of exactly 16 EntryObject members.