15.4. Відношення між класами
15.4.1. Типи відношень
Розглянемо подібності й відмінності між такими класами: квіти, маргаритки, червоні троянди, жовті троянди, пелюстки й сонечка. Відмітимо, що:
Маргаритка - квітка.
Троянда - (інша) квітка.
Червона й жовта троянди - троянди.
Пелюсток є частиною обох видів квітів.
Сонечка харчуються шкідниками, що вражають деякі квіти.
Із цього простого прикладу випливає, що класи, як і об'єкти, не існують окремо. У кожній проблемній області ключові абстракції взаємодіють багатьма способами, які ми повинні відобразити у в проекті.
Відношення між класами можуть означати одне із двох. По-перше, в них може бути щось загальне. Наприклад, і маргаритки, і троянди - це різновиди квітів: і ті, і інші мають яскраво пофарбовані пелюстки, видихають аромат і так далі. По-друге, може бути якийсь семантичний зв'язок. Наприклад, червоні троянди більше схожі на жовті троянди, ніж на маргаритки. Але між трояндами й маргаритками більше спільного, ніж між квітами й пелюстками. Також існує сібіотичний зв'язок між квітами й сонечками: сонечка захищають квіти від шкідників, які, у свою чергу, служать їжею сонечкам.
Відомі три основних типи відношень між класами. По-перше, це відношення "узагальнення/спеціалізація" (загальне й часткове), відоме як "is-a". Троянди є спеціалізованим частковим випадком квітів, тобто підкласом загальнішого класу "квіти". По-друге це відношення "ціле/ частина", відоме як "part of". Так, пелюстки є частиною квітів. По-третє, це семантичні, смислові відношення, асоціації. Наприклад, сонечка асоціюються із квітами - хоча, здавалося б, що в них спільного? Або ось: троянди й свічки - і те, і інше можна використовувати для прикраси столу.
Мови програмування виробили кілька загальних підходів до вираження відношень цих трьох типів. Зокрема, більшість об’єктно-орієнтованих мов безпосередньо підтримують різні комбінації таких видів відношень:
асоціація,
успадкування,
агрегація,
використання,
інсталювання,
метаклас.
Альтернативою успадкуванню є делегування, при цьому об'єкти розглядаються як прототипи, які делегують свою поведінку родинним їм об'єктам. Таким чином, класи стають не потрібними.
Із шести перерахованих видів відношень найзагальнішою є асоціація. Зазвичай аналітик констатує наявність асоціації й, поступово уточнюючи проект, перетворює її в якийсь спеціалізованіший зв'язок.
Успадкування, ймовірно, варто вважати семантично найцікавішим. Воно виражає відношення загального й частини. Однак одного успадкування недостатньо, щоб виразити всі різноманіття явищ і відношень життя. Корисна також агрегація, яка задає відношення цілого й частини між екземплярами класів. Не зайво додати відношення використання, що означає наявність зв'язку між екземплярами класів. "Метакласові" відношення - це щось зовсім інше, в явному вигляді воно зустрічається тільки в мовах Smalltalk і CLOS. Метаклас - це клас класів, що дозволяє нам трактувати класи як об'єкти.
15.4.2. Асоціація
Приклад 15.2. Бажаючи автоматизувати роздрібну торговельну мережу, ми виявляємо дві абстракції - товари й продажі. На рис. 15.4 показана асоціація, яку ми при цьому вбачаємо. Клас Product - це те, що ми продали згідно деякої угоди, а клас Sale - сама угода, в якій продано кілька товарів. Асоціація працює в обидві сторони: знаючи товар, можна вийти на угоду, в якій він був проданий, а маючи угоду, знайти, що було згідно неї продано.
Рис. 15.4. Асоціація.
В C++ це можна виразити за допомогою прихованих показників. Ось два коди оголошення відповідних класів:
class Product;
class Sale;
class Product {
public:
...
protected:
Sale* lastSale;
};
class Sale {
public:
...
protected:
Product** productSold;
};
Це асоціація вигляду "один-до-багатьох": кожний екземпляр товару відноситься тільки до однієї останньої продажі, в той час як кожний екземпляр Sale може вказувати на сукупність проданих товарів.
Семантичні залежності. Як видно з цього прикладу, асоціація - смисловий зв'язок. За замовчуванням, вона не має напрямків (якщо не зазначено інше, асоціація, як у цьому прикладі, розуміє двосторонній зв'язок) і не пояснює, як класи спілкуються один з одним (ми можемо тільки відзначити семантичну залежність, вказавши, які ролі класи відіграють). Однак саме це нам потрібно на ранній стадії аналізу. Отже, ми фіксуємо учасників, їх ролі й (як буде сказано далі) потужність відношень.
Потужність. У попередньому прикладі ми мали асоціацію "один до багатьох". Тим самим ми позначили її потужність (тобто, грубо говорячи, кількість учасників). На практиці важливо розрізняти три випадки потужності асоціації:
"один-до-одного"
"один-до-багатьох"
"багато-до-багатьох".
Відношення "один-до-одного" позначає дуже вузьку асоціацію. Наприклад, у роздрібній системі продажів прикладом міг би бути зв'язок між класом Sale і класом CreditCardTransaction: кожний продаж відповідає рівно одному зняттю грошей з цієї кредитної картки. Відношення "багато-до-багатьох" теж рідкісні. Наприклад, кожний об'єкт класу Customer (покупець) може ініціювати транзакцію з декількома об'єктами класу Saleperson (торговельний агент), і кожний торговельний агент може взаємодіяти з кількома покупцями. Всі три види потужності мають різного роду варіації.