7.8. Уточнення успадкування класів та розробка залежностей
Уточнюючи визначення класів та операцій, ретельно збільшуємо ступінь спадкоємності. Чим більше класів перебувають у відношенні спадкоємності, тим менше функцій, які реалізують операції цих класів, необхідно буде запрограмувати. Для збільшення ступеня спадкоємності потрібно:
перебудувати класи та операції;
виявити однакові (чи взаємно однозначно відповідні) операції та атрибути класів та визначити для цих класів абстрактний суперклас;
використовувати делегування операцій, коли успадкування семантично некоректне.
Іноді одна й та сама операція буває визначена в кількох класах, що дозволяє ввести загальний суперклас для цих класів, в якому і реалізується ця операція. Але найчастіше операції в різних класах бувають схожими, але не однаковими. Тоді потрібно спробувати внести неістотні зміни у визначення цих операцій, щоб вони стали однаковими, тобто мали однаковий інтерфейс та семантику. При цьому можна застосувати такі прийоми.
Якщо операції мають однакову семантику, але різне число формальних параметрів, можна додати відсутні параметри, але ігнорувати їх при виконанні операції; наприклад, операція відмальовування зображення на монохромний монітор не потребує параметра «колір», але його можна додати й не брати до уваги при виконанні операції.
Деякі операції мають менше параметрів, оскільки вони є окремими (частинними) випадками загальніших операцій; такі операції можна не реалізовувати, звести їх до загальніших операцій з відповідними значеннями параметрів, наприклад додавання елемента в кінець списку є частинний випадок вставки елемента у список.
Однакові за змістом атрибути чи операції різних класів можуть мати різні імена, такі атрибути (операції) можна перейменувати та перенести до класу, який є предком розглядуваних класів.
Операція може бути визначена не в усіх класах деякої групи класів, хоча можна, проте, винести її до загального суперкласу, перевизначивши її у підкласах як порожню там, де вона не потрібна.
Рис. 81. Реалізація стека з використанням успадкування (а) та делегуванням (б)
Використання делегування операцій можна пояснити таким прикладом (рис. 81). Клас «стек» близький класу «список», причому операціям стека push та pop відповідають явні частинні випадки операцій списку add та remove. Якщо реалізувати клас «стек» як підклас класу «список», то доведеться застосувати замість операцій push та pop загальніші операції add та remove, стежачи за їх параметрами, щоб уникнути запису або читання із середини стека; це не зручно, бо може призвести до помилок. Значно краще оголосити клас «список» тілом класу «стек» (делегування), звертаючись до операцій списку з допомогою операцій стека. При цьому, не замінюючи класу «список», ми замінюємо його інтерфейс інтерфейсом класу «стек».
Залежності — це «клей» об’єктної моделі, оскільки саме вони дозволяють розглядати модель як щось ціле, а не просто як множину класів.
Односторонні залежності можна реалізувати за допомогою посилання, або покажчика (рис. 82). При цьому, якщо кратність залежності дорівнює одиниці, їй відповідає один покажчик, якщо кратність більша за одиницю, — множина покажчиків.
Спосіб реалізації двосторонньої залежності за допомогою покажчиків ілюструє рис. 83.
Рис. 82. Реалізація односторонньої залежності |
Рис. 83. Реалізація двосторонньої залежності |
Спосіб реалізації залежностей за допомогою таблиці (як у реляційних базах даних) ілюструє рис. 84.
Рис. 84. Реалізація залежностей з допомогою таблиці
При реалізації залежностей за допомогою покажчиків атрибути залежностей (зв’язків) переносяться в один із класів, які беруть участь у залежності