Учасники паттерна. 1. Iterator – ітератор. Інтерфейс Ітератора повинний бути реалізований всіма Конкретними ітераторами (як і вхідні в нього методи перебору елементів):

1. Iterator – ітератор. Інтерфейс Ітератора повинний бути реалізований всіма Конкретними ітераторами (як і вхідні в нього методи перебору елементів):

- визначає інтерфейс для доступу й обходу елементів.

2. ConcreteІterator – конкретний ітератор:

- реалізує інтерфейс класу Iterator;

- стежить за поточною позицією при обході агрегату.

3. Aggregate – агрегат. Наявність загального інтерфейсу зручна для клієнта, оскільки клієнт відокремлюється від реалізації колекції об’єктів:

- визначає інтерфейс для створення об’єкта-ітератора.

4. ConcreteAggregate – конкретний агрегат:

- реалізує інтерфейс створення ітератора і повертає екземпляр відповідного класу ConcreteІterator.

Абстракція Iterator має основоположне значення для технології, званої «узагальнене програмування». Ця технологія чітко розділяє такі поняття як «алгоритм» і «структура даних». Мотивуючі чинники: сприяння компонентної розробки, підвищення продуктивності і зниження витрат на управління.

Результати використання:

- паттерн Ітератор забезпечує перебір елементів колекції без розкриття реалізації;

- паттерн дозволяє перебирати елементи колекції, не знаючи, як реалізована колекція;

- при наявності універсального механізму перебору елементів можна написати поліморфний код, що працює з будь-якими колекціями, здатними створити Іterator;

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

Iterator може застосовуватися для обходу складних структур, створюваних Composite. Для створення екземпляра підкласу Iterator поліморфні ітератори використовують Factory Method.

Паттерн Команда (Command)

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

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

Мотивація застосування. Використовуйте паттерн Command якщо:

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

- необхідно параметризувати об’єкти виконуваною дією, ставити запити в чергу або підтримувати операції скасування (undo) і повтору (redo) дій;

- потрібен об’єктно-орієнтований аналог функції зворотного виклику в процедурному програмуванні. Callback (англ. call – виклик, англ. back – зворотний) або функція зворотного виклику в програмуванні – це передача коду, що виконується, в якості одного з параметрів іншого коду. Зворотний виклик дозволяє в функції виконувати код, що задається в аргументах при її виклику. Цей код може бути визначений в інших контекстах програмного коду і бути недоступним для прямого виклику з цієї функції. Деякі алгоритмічні задачі в якості власних вхідних даних мають не тільки числа або об’єкти, але і дії (алгоритми), що природним чином задаються як зворотні виклики.

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

1. Давайте проаналізуємо взаємодію між відвідувачем, офіціанткою, замовленнями і кухарем. Кафе можна розглядати як модель паттерну ОО-проектування, що відокремлює об’єкт-джерело запиту від об’єкта, що приймає і виконує ці запити (рис. 6.14) [10].

В рамках проектування програмної системи із використанням принципів ООП ця предметна область прийме наступний вигляд (рис. 6.15).

Бланк замовлення інкапсулює запит на приготування страв. Будемо розглядати бланк замовлення як об’єкт запиту на приготування їжі. Як і будь-який інший об’єкт, він може передаватися від офіціантки на стійку або наступній офіціантці, яка змінює першу. Його інтерфейс складається з єдиного методу orderUp (), що інкапсулює всі дії, необхідні для приготування. Крім того, замовлення містить посилання на об’єкт, який має готувати страви. Інкапсуляція полягає в тому, що офіціантку не цікавить вміст замовлення і те, хто буде його виконувати; вона тільки кладе замовлення на стійку і повідомляє про нове замовлення.

Рис. 6.14. Схема проблемної предметної області

Рис. 6.15. Предметна область із застосуванням паттерна

Завдання офіціантки отримати замовлення і викликати його метод orderUp (). Робота офіціантки проста: вона отримує замовлення і продовжує обслуговувати відвідувачів, поки не повернеться до стійки і не викличе метод orderUp () для виконання замовлення. Як згадувалося раніше, офіціантка не турбується про те, що міститься в замовленні і хто його буде виконувати. Їй відомо лише те, що в замовленні є метод orderUp (), який необхідно викликати для виконання операції. Протягом робочого дня метод takeOrder () класу офіціантки викликається з безліччю різних замовлень від різних відвідувачів, але це офіціантку не бентежить. Вона знає, що всі замовлення підтримують метод orderUp (), який необхідно викликати для приготування страв.

Кухар володіє всією інформацією, необхідною для приготування страв. Кухар – той об’єкт, який вміє виконувати замовлення. Після того, як офіціантка викличе метод orderUp (), за справу береться кухар – він реалізує всі методи, необхідні для створення страв. Зверніть увагу: офіціантка і кухар нічим не пов’язані. Вся інформація про замовлені страви інкапсульована в замовленні; офіціантка тільки викликає метод для кожного замовлення, щоб воно було виконано. Кухар отримує свої інструкції з бланка замовлення; йому ніколи не доводиться взаємодіяти з офіціанткою безпосередньо.

Для розробки архітектури програмної системи, описаної предметної області доцільно застосувати паттерн Команда. В рамках його термінології предметна область буде виглядати як це показано на рис. 6.16.

Рис. 6.16. Паттерн Команда в термінах предметної області

2. Розглянемо наступний приклад [10]: у APІ пульта керування код, викликуваний при натисканні кнопки, повинний відокремлюватися від об’єктів конкретних класів, що виконують ці запити. Чому б не зв’язати кожну кнопку пульта з об’єктом, аналогічним об’єкту замовлення з кафе? При натисканні кнопки буде викликатися аналог методу orderUp () такого об’єкта, причому пульт не буде нічого знати про те, як виконуються дії і які об’єкти задіяні у виконанні операції. Ми збираємося зв’язати кожну кнопку пульта з командою. Таким чином, пульту відводиться роль ініціатора. При натисканні кнопки викликається метод execute () відповідної команди, що приводить до виконання операції з одержувачем (освітлювальною системою, кондиціонером і т.д.) (рис. 6.17).

Рис. 6.17. Схема роботи пульта в терміна паттерна Команда

3. Черги запитів. Команди забезпечують механізм інкапсуляції «обчислювальних блоків» (одержувач + набір операцій) і передачі їх у вигляді повноцінних об’єктів. При цьому самі операції можуть ініціюватися набагато пізніше створення об’єкта команди в клієнтському додатку (і навіть в іншому програмному потоці). Цей сценарій знаходить застосування в багатьох корисних додатках: планувальниках, пулах потоків, чергах завдань і т.д.

Візьмемо чергу завдань: команди ставляться в кінець черги, що обслуговується групою програмних потоків. Потоки витягають команду з черги, викликають її метод execute (), очікують завершення виклику, знищують поточний об’єкт команди і переходять до наступної команди (рис. 6.18).

Рис. 6.18. Схема черги запитів

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

Структура паттерну Команда представлена у вигляді діаграми класів на рис. 6.19.

Рис. 6.19. Діаграма класів паттерна Команда

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