Apologies if "Composition Hierarchy" isn't a thing, but I'll explain what I mean by it in the question.
There isn't any OO programmer who hasn't come across a variation of "Keep inheritance hierarchies flat" or "Prefer composition over inheritance" and so on. However, deep composition hierarchies seem problematic as well.
Let's say we need a collection of reports detailing the results of an experiment:
class Model {
// ... interface
Array<Result> m_results;
}
Each result has certain properties. These include the time of the experiment, as well as some meta-data from each stage of the experiment:
enum Stage {
Pre = 1,
Post
};
class Result {
// ... interface
Epoch m_epoch;
Map<Stage, ExperimentModules> m_modules;
}
Ok, great. Now, each experiment module has a string describing the outcome of the experiment, as well as a collection of references to experimental sample sets:
class ExperimentalModules {
// ... interface
String m_reportText;
Array<Sample> m_entities;
}
And then each sample has... well, you get the picture.
The problem is that if I am modeling objects from my application domain, this seems like a very natural fit, but at the end of the day, a Result
is just a dumb container of data! It doesn't seem worthwhile to create a large group of classes for it.
Assuming that the data structures and classes shown above correctly model the relationships in the application domain, is there a better way to model such a "result", without resorting to a deep composition hierarchy? Is there any external context that would help you determine whether such a design is a good one or not?