Учасники паттерна. - оголошує інтерфейс для виконання операції;

1. Command – команда:

- оголошує інтерфейс для виконання операції;

- для активізації команди викликається метод execute ().

2. ConcreteCommand – конкретна команда:

- визначає зв’язок між об’єктом-одержувачем Receiver і дією;

- реалізує операцію Execute шляхом виклику відповідних операцій об’єкта Receiver.

3. Client – клієнт:

- створює об’єкт класу ConcreteCommand і встановлює його одержувача.

4. Invoker – ініціатор:

- зберігає команду і у визначений момент віддає запит на її виконання;

- звертається до команди для виконання запиту.

5. Receiver – одержувач:

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

Відносини учасників паттерна. Інтерфейс командного об’єкта визначається абстрактним базовим класом Command і в найпростішому випадку має єдиний метод execute (). Похідні класи визначають одержувача запиту (курсор на об’єкт-одержувач) і необхідну для виконання операцію (метод цього об’єкта). Метод execute () підкласів Command просто викликає потрібну операцію одержувача.

Спочатку клієнт створює об’єкт ConcreteCommand, конфігуруючи його одержувачем запиту. Клієнт викликає setCommand () для збереження об’єкта команди в ініціаторі. Ініціатор використовує його при відправці запиту, викликаючи метод execute (). Потім клієнт звертається до ініціатору із запитом на виконання команди. Команда, завантажена ініціатором, може як знищуватися після виконання, так і залишатися для повторного використання. Цей алгоритм нагадує роботу функції зворотного виклику в процедурному програмуванні – функція реєструється, щоб бути викликаною пізніше.

Паттерн Command відокремлює об’єкт, який ініціює операцію, від об’єкта, який знає, як її виконати. Єдине, що повинен знати ініціатор, це як відправити команду. Це надає системі гнучкість: дозволяє здійснювати динамічну заміну команд, використовувати складні складені команди, здійснювати скасування операцій.

На наступній діаграмі (рис. 6.20) видно, як Command розриває зв’язок між ініціатором та отримувачем (а також запитом, який повинен виконати останній) [12].

Рис. 6.20. Діаграма послідовності взаємодії класів паттерна

Об’єкт команди інкапсулює запит за допомогою прив’язки набору операцій до конкретного одержувача. Для цього інформація про операцію й одержувача «упаковується» в об’єкті з єдиним методом execute (). При виклику метода execute () виконується операція з даним одержувачем. Зовнішні об’єкти не знають, які саме операції виконуються, і з яким одержувачем; вони тільки знають, що при виклику методу execute () їх запит буде виконаний.

Результати використання. Результати застосування паттерну Команда такі:

- команда розриває зв’язок між об’єктом, який ініціює операцію, і об’єктом, що має інформацію про те, як її виконати;

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

- з простих команд можна збирати складені. В загальному випадку складені команди описуються паттерном Компонувальник;

- додавати нові команди легко, оскільки ніякі існуючі класи змінювати не потрібно;

- у паттерні можна створювати об’єкти NoCommand, що є прикладом порожнього (null) об’єкта. Порожні об’єкти застосовуються тоді, коли повернути «повноцінний» об’єкт неможливо, але необхідно позбавити клієнта від необхідності перевіряти null -посилання. Так, при відсутності повноцінного об’єкта, який можна було б зв’язати з командою, використовується сурогатний об’єкт NoCommand з фіктивним методом execute. Порожні об’єкти використовуються в багатьох паттернах проектування, а деякі автори навіть вважають їх самостійним паттерном;

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

Паттерн Спостерігач (Observer)

Призначення. Паттерн Спостерігач – це паттерн поведінки, який визначає залежність типу «один до багатьох» між об’єктами таким чином, що при зміні стану одного об’єкта всі залежні від нього сповіщаються про це і автоматично оновлюються [30].

Частота використання

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

Паттерн Observer знаходить широке застосування в системах користувальницького інтерфейсу, в яких дані та їх подання («вигляд») відокремлені один від одного. При зміні даних повинні бути змінені всі подання цих даних (наприклад, у вигляді таблиці, графіку чи діаграми).

Використовуйте паттерн коли:

- необхідно підтримувати узгоджений стан взаємопов’язаних класів;

- при модифікації одного об’єкта потрібно змінити інші, і ви не знаєте, скільки саме об’єктів потрібно змінити;

- один об’єкт повинен сповіщати інших про зміну свого стану, нічого не знаючи про сповіщені ним об’єкти.

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