• Команда

Ідея шаблону „команда” полягає в тому, щоби розвинути та поглибити принцип “бесіди об’єктів” – повідомлення, якими спілкуються об’єкти, в свою чергу програмно оформити як об’єкти.

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

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

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

Огортання повідомлень або команд в об’єкти дозволяє використовувати наслідування та поліморфізм: зокрема, зазначений вище метод „виконати команду” варто робити поліморфним та по-своєму визначати для конкретних різновидів команд.

• Типовий приклад використання

Нехай є клас „Меню”, об’єкт якого містить колекцію об’єктів класу „Елемент меню”.

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

Об’єкт „Елемент меню” має серед членів-даних текст та об’єкт класу „Команда”.

Тоді при створенні елементів меню достатньо кожному його елементу призначити певний об’єкт-команду з відповідно визначеним методом „виконати”.

Типова реалізація методу „виконати” полягає в тому, щоб викликати конкретний метод об’єкта-виконавця, посилання якого міститься в об’єкті-команді (наприклад, об’єкт, що інкапсулює команду „видалити”, має посилання на об’єкт „документ” та викликає метод „видалити” останнього).

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

Об’єкти – учасники „бесіди” можуть передавати один одному об’єкти-команди, ставити їх в чергу, відмовлятися від їх обробки тощо.

Об’єкт, що ініціює команду, не знає, якому об’єкту-виконавцю він делегує свою функцію. Це дозволяє „відв’язати” учасників „бесіди об’єктів” один від одного.

• Посередник

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

Цим об’єктам потрібно звертатися один до одного з викликами методів.

„Прямий” підхід полягає в тому, щоб кожен об’єкт в системі містив посилання на всі ті сусідні об’єкти, до яких він має звертатися.

Недолік такого підходу – сильні перехресні зв’язки між об’єктами, що порушує принцип декомпозиції системи на максимально незалежні компоненти та зменшує придатність об’єктів та підсистем для повторного використання, а також утруднює модифікацію системи.

В найгіршому випадку кожен з об’єктів повинен мати посилання на будь-який інший, тоді якщо кількість об’єктів в системі – n, то кількість перехресних зв’язків має порядок n².

Шаблон „Посередник” призначений для того, щоб радикально зменшити кількість перехресних зв’язків, звівши її до порядку n.

Ідея шаблону полягає в тому, щоб зв’язки між об’єктами інкапсулювати в ще одному, допоміжному об’єкті, який виконує службову функцію „комутатора” чи „диспетчерського центру”.

Замість того, щоби об’єкт А прямо звертався до об’єктів В, С і т.д. і таким чином знав посилання на них, він знає лише посилання на посередника М та звертається лише до нього; той, в свою чергу, знає посилання на всі об’єкти, в тому числі А, В, С, і спрямовує повідомлення до них.