Przepraszam, jeśli „Hierarchia składu” nie jest rzeczą, ale wyjaśnię, co mam na myśli w pytaniu.
Nie ma programisty OO, który nie spotkałby się z odmianą „Zachowaj płaskie hierarchie dziedziczenia” lub „Preferuj kompozycję nad dziedziczeniem” i tak dalej. Problematyczne są jednak również głębokie hierarchie kompozycji.
Załóżmy, że potrzebujemy zbioru raportów szczegółowo opisujących wyniki eksperymentu:
class Model {
// ... interface
Array<Result> m_results;
}
Każdy wynik ma określone właściwości. Obejmują one czas eksperymentu, a także niektóre metadane z każdego etapu eksperymentu:
enum Stage {
Pre = 1,
Post
};
class Result {
// ... interface
Epoch m_epoch;
Map<Stage, ExperimentModules> m_modules;
}
Ok świetnie. Teraz każdy moduł eksperymentu ma ciąg opisujący wynik eksperymentu, a także zbiór odniesień do eksperymentalnych zestawów próbek:
class ExperimentalModules {
// ... interface
String m_reportText;
Array<Sample> m_entities;
}
A potem każda próbka ma ... no cóż, dostajesz obraz.
Problem polega na tym, że jeśli modeluję obiekty z mojej domeny aplikacji, wydaje się to bardzo naturalne dopasowanie, ale pod koniec dnia jest Resultto po prostu głupi kontener danych! Nie wydaje się opłacalne tworzenie dla niego dużej grupy klas.
Zakładając, że struktury danych i klasy pokazane powyżej poprawnie modelują relacje w domenie aplikacji, czy istnieje lepszy sposób na modelowanie takiego „wyniku” bez uciekania się do głębokiej hierarchii kompozycji? Czy istnieje jakiś kontekst zewnętrzny, który pomógłby ustalić, czy taki projekt jest dobry, czy nie?