Перваги та недоліки спадкування і композиції

Спадкування класу визначається статично на етапі компіляції, його простіше використати, оскільки воно прямо підтримано мовою програмування. У випадку спадкування класів спрощується також завдання модифікації існуючої реалізації. Якщо підклас заміщає лише деякі операції, то можуть виявитися порушеними й інші успадковані операції, оскільки не виключено, що вони викликають заміщені.

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

Залежність від реалізації може викликати проблеми при спробі повторного використання підкласу. Якщо хоча б один аспект успадкованої реалізації непридатний для нової предметної області, то доводиться переписувати батьківський клас або заміняти його чимсь більше підходящим. Така залежність обмежує гнучкість і можливості повторного використання. Із проблемою можна впоратися, якщо успадковувати тільки абстрактним класам, оскільки в них зазвичай зовсім немає реалізації або вона мінімальна.

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

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

Це підводить нас до ще одного правила об’єктно-орієнтованого проектування: композиції спадкування класу.

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

Поиск по сайту: