Ci scusiamo se "Gerarchia di composizione" non è una cosa, ma spiegherò cosa intendo con la domanda.
Non esiste alcun programmatore OO che non abbia riscontrato una variazione di "Mantieni le gerarchie di ereditarietà piatte" o "Preferisci la composizione sull'ereditarietà" e così via. Tuttavia, anche le gerarchie di composizione profonde sembrano problematiche.
Diciamo che abbiamo bisogno di una raccolta di rapporti che descrivono in dettaglio i risultati di un esperimento:
class Model {
// ... interface
Array<Result> m_results;
}
Ogni risultato ha determinate proprietà. Questi includono il tempo dell'esperimento e alcuni metadati di ogni fase dell'esperimento:
enum Stage {
Pre = 1,
Post
};
class Result {
// ... interface
Epoch m_epoch;
Map<Stage, ExperimentModules> m_modules;
}
Ok, fantastico. Ora, ogni modulo sperimentale ha una stringa che descrive il risultato dell'esperimento, nonché una raccolta di riferimenti a insiemi di campioni sperimentali:
class ExperimentalModules {
// ... interface
String m_reportText;
Array<Sample> m_entities;
}
E poi ogni campione ha ... beh, ottieni l'immagine.
Il problema è che se sto modellando oggetti dal mio dominio applicativo, questo sembra un adattamento molto naturale, ma alla fine della giornata, un Result è solo un contenitore di dati stupido! Non sembra utile creare un vasto gruppo di classi per questo.
Supponendo che le strutture dati e le classi mostrate sopra modellano correttamente le relazioni nel dominio dell'applicazione, esiste un modo migliore per modellare un tale "risultato", senza ricorrere a una gerarchia di composizione profonda? Esiste un contesto esterno che potrebbe aiutarti a determinare se un tale progetto è buono o no?