Извиняюсь, если «Составная иерархия» не вещь, но я объясню, что я имею в виду под этим вопросом.
Нет ни одного программиста ОО, который бы не сталкивался с вариациями «Сохраняйте иерархию наследования плоскими», «Предпочитайте композицию над наследованием» и так далее. Тем не менее, глубокие композиционные иерархии также кажутся проблематичными.
Допустим, нам нужна коллекция отчетов, детализирующих результаты эксперимента:
class Model {
// ... interface
Array<Result> m_results;
}
Каждый результат имеет определенные свойства. К ним относятся время эксперимента, а также некоторые метаданные с каждой стадии эксперимента:
enum Stage {
Pre = 1,
Post
};
class Result {
// ... interface
Epoch m_epoch;
Map<Stage, ExperimentModules> m_modules;
}
Ок, отлично. Теперь у каждого экспериментального модуля есть строка, описывающая результаты эксперимента, а также коллекция ссылок на экспериментальные наборы образцов:
class ExperimentalModules {
// ... interface
String m_reportText;
Array<Sample> m_entities;
}
И тогда каждый образец имеет ... ну, вы получите картину.
Проблема в том, что, если я моделирую объекты из моего домена приложения, это кажется очень естественным соответствием, но в конце концов, это Resultпросто тупой контейнер данных! Кажется, не стоит создавать для него большую группу классов.
Если предположить, что структуры данных и классы, показанные выше, правильно моделируют отношения в предметной области, есть ли лучший способ моделировать такой «результат», не прибегая к глубокой иерархии композиции? Есть ли какой-то внешний контекст, который поможет вам определить, является ли такой дизайн хорошим или нет?