Page 70 - 4190

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

кованості" або побудова абстракції з відображення (відповідності)
користувачів у групи і груп у користувачів. Даний підхід має такі пе-
реваги: користувачі і групи відокремлені один від одного, відобра-

женнями легко управляти одночасно і абстракція відображення може
бути розширена в майбутньому шляхом визначення похідних класів
(рис. 7.3).

Рисунок 7.3 – Структурна схема відображення користувачів у групи і груп
у користувачів

Розбиття системи на безліч об'єктів в загальному випадку підви-
щує міру повторного використання, проте безліч взаємозв'язків між
цими об'єктами, як правило, приводить до зворотного ефекту. Щоб

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

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

Патерн Mediator замінює взаємодію "усе з усіма" взаємодією
"один з усіма".
Приклад раціонального використання патерну Mediator - моде-

70