15.2.3. Агрегація

Семантика. У той час, як зв'язки позначають рівноправні або "клієнт-серверні" відношення між об'єктами, агрегація описує відношення цілого й частини, що приводить до відповідної ієрархії об'єктів, причому, ідучи від цілого (агрегату), ми можемо прийти до його частин (атрибутів). У цьому змісті агрегація - спеціалізований окремий випадок асоціації. На рис. 15.3 об'єкт rampController має зв'язок з об'єктом growingRamp і атрибут h класу Heater (нагрівач). У цьому випадку rampController - ціле, a h - його частина. Інакше кажучи, h - частина стану rampController. Виходячи з rampController, можна знайти відповідний нагрівач. Однак через h не можна знайти утримуючий його об'єкт (його також називають контейнером), якщо тільки відомості про нього не є випадково частиною стану h.

Рис. 15.3. Агрегація.

Агрегація може означати фізичне входження одного об'єкта в інший, але не обов'язково. Літак складається із крил, двигунів, шасі й інших частин. З іншої сторони, відношення акціонера до його акціями - це агрегація, що не передбачає фізичного включення. Акціонер монопольно володіє своїми акціями, але вони в нього не входять фізично. Це, безсумнівно, відношення агрегації, але скоріше концептуальне, ніж фізичне за своєю природою.

Вибираючи одне із двох - зв'язок або агрегацію - треба мати на увазі таке. Агрегація іноді переконливіша, оскільки дозволяє сховати частини в цілому. Іноді навпаки краще використовувати зв'язок, оскільки він слабший й менше обмежений. Приймаючи рішення, треба зважити все.

Об'єкт, що є атрибутом іншого об'єкта (агрегату), має зв'язок зі своїм агрегатом. Через цей зв'язок агрегат може посилати йому повідомлення.

Приклад 15.1. Додамо в специфікацію класу TemperatureController опис нагрівача:

Heater h;

Після цього кожний об'єкт TemperatureController буде мати свій нагрівач. Відповідно до нашого визначення класу Heater у попередній главі ми повинні включити нагрівач при створенні нового контролера, тому що сам цей клас не передбачає конструктора за замовчуванням. Ми могли б визначити конструктор класу TemperatureController у такий спосіб:

TemperatureController::TemperatureController(Location 1)

: h(1) {}

15.3. Природа класів

15.3.1. Що таке клас?

Поняття класу й об'єкта настільки тісно зв'язані, що неможливо говорити про об'єкт безвідносно до його класу. Однак існує важлива відмінність цих двох понять. У той час як об'єкт позначає конкретну сутність, існуючу в часі й у просторі, клас визначає лише абстракцію істотного в об'єкті. Таким чином, можна говорити про клас "Ссавці", що включає характеристики, загальні для всіх ссавців. Для вказівки на конкретного представника ссавців необхідно сказати "це - ссавець". 

У загально-зрозумілих термінах можна дати наступне визначення класу: група, множина або вид із загальними властивостями або загальною властивістю, різновидами, які відрізняються від всього решта якістю, можливостями або умовами. У контексті об’єктно-орієнтованого аналізу дамо таке визначення класу:

Клас - це якась множина об'єктів, що мають спільну структуру й спільну поведінку.

Будь-який конкретний об'єкт є просто екземпляром класу. Що ж не є класом? Об'єкт не є класом, хоча надалі ми побачимо, що клас може бути об'єктом. Об'єкти, які не зв'язані спільною структурою й поведінкою, не можна об'єднати в клас, тому що за означенням вони не зв'язані між собою нічим, крім того, що всі вони об'єкти.

Важливо відзначити, що класи, як їх розуміють у більшості існуючих мовах програмування, необхідні, але не достатні для декомпозиції складних систем. Деякі абстракції настільки складні, що не можуть бути виражені в термінах простого опису класу. Наприклад, на досить високому рівні абстракції графічний інтерфейс користувача, база даних або система обліку як ціле, це явні об'єкти, але не класи. Краще вважати їх якимись сукупностями (кластерами) класів, що співпрацюють. Такі кластери називають компонентами.