Вибачте, якщо "Ієрархія композиції" - це не річ, але я поясню, що я маю на увазі під питанням.
Немає жодного програміста ОО, який би не стикався з варіантами "Зберігайте ієрархії спадкування рівними" або "Віддавайте перевагу композиції над успадкуванням" тощо. Однак ієрархії глибокого складу також видаються проблематичними.
Скажімо, нам потрібна збірка звітів із деталізацією результатів експерименту:
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це просто німий контейнер даних! Створювати для цього велику групу класів не варто.
Якщо припустити, що наведені вище структури даних та класи правильно моделюють взаємозв'язки в області додатків, чи є кращий спосіб моделювати такий "результат", не вдаючись до глибокої ієрархії композиції? Чи є якийсь зовнішній контекст, який допоможе вам визначити, чи є такий дизайн хорошим чи ні?