Відносини учасників паттерна. Колеги посилають запити посереднику й одержують запити від нього

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

Особливості програмної реалізації. Послідовність програмних дій для реалізації паттерна може бути наступна [31]:

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

- інкапсулюйте всі взаємодії в абстракцію нового класу;

- створіть екземпляр цього нового класу. Об’єкти-колеги для взаємодії один з одним використовують тільки цей об’єкт;

- знайдіть правильний баланс між принципом слабкої зв’язаності і принципом розподілу відповідальності;

- будьте уважні і не створюйте «об’єкт-контролер» замість об’єкта-посередника.

Майте на увазі, що при реалізації паттерну Посередник може відбуватися:

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

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

Інший підхід: у класі Mediator визначається спеціалізований інтерфейс повідомлення, який дозволяє колегам обмінюватися інформацією більш вільно. Для Windows застосовується деяка форма делегування: спілкуючись з посередником, колега передає себе в якості аргументу, даючи посереднику можливість ідентифікувати відправника.

Mediator і Observer є конкуруючими паттернами. Якщо Observer розподіляє взаємодію за допомогою об’єктів «спостерігач» і «суб’єкт», то Mediator використовує об’єкт-посередник для інкапсуляції взаємодії між іншими об’єктами. Було виявлено, що легше зробити повторно використовуваними Спостерігачів та Суб’єктів, ніж Посередників.

З іншого боку, Mediator може використовувати Observer для динамічної реєстрації колег і їх взаємодії з посередником.

Mediator схожий на Faсade в тому, що він абстрагує функціональність існуючих класів. Mediator абстрагує/централізує взаємодію між об’єктами-колегами, додає нову функціональність і відомий всім об’єктам-колегам (тобто визначає двоспрямований протокол взаємодії). Facade, навпаки, визначає більш простий інтерфейс підсистеми, не додаючи нової функціональності, і невідомий класам підсистеми (тобто має односпрямований протокол взаємодії, тобто запити надсилаються в підсистему, але не навпаки).

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