Обговорення паттернів поведінки

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

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

Інкапсуляція варіацій. Інкапсуляція варіацій – це елемент багатьох паттернів поведінки [14]. Якщо частина програми піддається періодичним змінам, паттерни дозволяють визначити об’єкт для інкапсуляції такого аспекту. Інші частини програми, що залежать від даного аспекту, можуть кооперуватися з ним. Зазвичай, паттерни поведінки створюють абстрактний клас, за допомогою якого описується об’єкт, який інкапсулюється. Своєю назвою паттерни зобов’язані цьому об’єкту. Наприклад:

- об’єкт Стратегія інкапсулює алгоритм;

- об’єкт Стан інкапсулює поведінку, що залежить від стану;

- об’єкт Посередник інкапсулює протокол спілкування між об’єктами;

- об’єкт Ітератор інкапсулює спосіб доступу й обходу компонентів складеного об’єкта.

Перераховані паттерни описують аспекти програми, які піддаються змінам. У більшості паттернів фігурують два види об’єктів: новий об’єкт (або об’єкти), що інкапсулює аспект, і існуючий об’єкт (або об’єкти), що користується новим. Якби не паттерн, то функціональність нових об’єктів довелося б робити невід’ємною частиною існуючих. Наприклад, код об’єкта-стратегії, імовірно, був би «зашитий» у контекст стратегії, а код об’єкта-стану був би реалізований безпосередньо в контексті стану. Але не всі паттерни поведінки розбивають функціональність у такий спосіб. Наприклад, паттерн Ланцюжок зобов’язань пов’язаний з довільною кількістю об’єктів (тобто ланцюжком), причому всі вони можуть вже існувати в системі.

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

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

Інші паттерни визначають об’єкти, що виступають у ролі «чарівних паличок», що передаються від одного власника до іншого й активізуються в майбутньому. До цієї категорії відносяться Команда і Зберігач. У паттерні Команда такою «паличкою» є запит, а в Зберігачі вона представляє внутрішній стан об’єкта у визначений момент. Така «паличка» може мати складну внутрішню структуру, хоча клієнт про це нічого не знає. Але навіть тут є розходження. В паттерні Команда важливу роль грає поліморфізм, оскільки виконання об’єкта-команди – поліморфна операція. Навпроти, інтерфейс Зберігача настільки «вузький», що його можна передавати лише як значення. Тому цілком імовірно, що Зберігач не надає поліморфних операцій своїм клієнтам.

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

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

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

Поділ одержувачів і відправників. Коли взаємодіючі об’єкти прямо посилаються один на одного, вони стають залежними, а це може негативно позначитися на повторному використанні системи і розбивці її на рівні. Паттерни Команда, Спостерігач, Посередник і Ланцюжок зобов’язань задають різні способи поділу одержувачів і відправників запитів. Кожний спосіб має свої достоїнства і недоліки.

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

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

Контрольні запитання

1. Яким чином паттерни Chaіn of Responsіbіlіty, Command, Medіator і Observer розділяють відправника й одержувача запиту?

2. Яким чином паттерн Chaіn of Responsіbіlіty може використовувати паттерн Command?

3. Яким чином паттерн Command може використовувати паттерн Memento?

4. Яким чином MacroCommands можуть реалізовуватися, використовуючи паттерн Composіte?

5. В якому випадку паттерн Command діє як паттерн Prototype?

6. Що спільного між застосуванням паттернів Medіator і Observer і в чому розходження?

7. Що спільного між паттернами Medіator і Facade?

8. Яким чином паттерн Іterator може використовувати паттерн Memento?

9. Що спільного між паттернами State і Strategy?

10. Яким чином паттерн State може використовувати паттерн Sіngleton?

11. Яка реалізація паттерна Strategy подібна реалізації паттерна State?

12. У чому полягає спільність паттернів Strategy і Template Method, і в чому розходження?

13. Дати порівняльний аналіз можливостей паттернів Vіsіtor і Command.

14. Дати порівняльний аналіз паттернів Adapter, Decorator і Facade.

15. Дати порівняльний аналіз паттернів Adapter і Proxy.

16. Дати порівняльний аналіз паттернів Decorator і Chaіn of Responsіbіlіty.

17. Яким чином паттерн Decorator і паттерн Strategy дозволяють змінити об’єкт?

18. Чому паттерни Composіte і Decorator часто використовуються спільно?

19. Чому паттерни Facade і Sіngleton часто використовуються спільно?

20. На яких стадіях проектування класів об’єктно-орієнтованої програми використовуються паттерни Adapter і Brіdge?

РЕКОМЕНДОВАНА ЛІТЕРАТУРА

1. Павловская Т. А., Щупак Ю. А. C++. Объектно-ориентированное программирование: Практикум. — СПб.: Питер, 2006. — 265 с.

2. Brett D.McLanghlin, Gary Pollice, David West. Head first object-oriented analysis and design. — O’Reilly Media, Inc, 2007. —632 p.

3. Павловская Т. А. С#. Программирование на языке высокого уровня. Учебник для вузов. — СПб.: Питер, 2009. — 432 с

4. Климов Л. П. С#. Советы программистам. — СПб.: БХВ-Петербург, 2008. — 544 с.

5. Уотсон, Карл и, Нейгел, Кристиан, Педерсен, Якоб Хаммер, Рид, Джон Д., Скиннер, Морган, Уайт, Эрик. Visual С# 2008: базовый курс: Пер. с англ. — М.: Вильямс, 2009. — 1216 с.

6. Д. Нильссон. Применение проблемно-ориентированного проектирования и шаблонов проектирования приложений с примера на С# и.NET. — М.: Вильямс, 2008. — 560с.

7. Д. Кириевски. Рефакторинг с использованием шаблонов. — М.: Вильямс, 2006. — 400с.

8. Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. — М.: Издательско-торговый дом «Русская Редакция». — СПб.: Питер, 2005. — 896 с.

9. Э. Эванс. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем. — М.: Вильямс, 2011. — 448 с.

10. Э. Фримен, Э. Фримен, К. Сьерра, Б. Гейтс. Паттерны проектирования. — СПб: Питер, 2011. — 656 с.

11. Влиссидес Джон. Применение шаблонов проектирования. Дополнительные штрихи. — Пер. с англ. — М.: Издательский дом "Вильямс", 2003. — 144 с.

12. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб: Питер, 2001. — 368 с.

13. Спольски Дж.Х. Лучшие примеры разработки ПО. — СПб: Питер, 2007. — 208 c.

14. Allan Halloway, James R. Trott. Design Patterns Explained: A New Perspective on Object-Oriented Design, 2004. — 255 p.

15. Будай А. Дизайн-паттерни – простіше простого. — Львів, 2012. — 90с.

16. James W. Cooper. Introduction to design patterns in C#. — IBM T J Watson Research Center, 2002. — 424 p.

17. Benny G. Serevsen. Design Patterns. — BGS Consulting ApS, 2008. — 224 p.

18. В.А. Биллиг. Объектное программирование в классах на С#. — Интернет-университет ИНТУИТ, 2008. — 360 с.

Навчальне видання

Конспект лекцій з дисципліни „Моделювання та аналіз програмного забезпечення” для студентів напряму 6.050103 „Програмна інженерія” / К.М. Ялова, В.В. Завгородній // Дніпродзержинськ: ДДТУ, 2012. – 151 с.

Укладачі: к.т.н., ст.викл. Ялова К.М.

ст. викл. Завгородній В.В.

Підписано до друку

Формат Обсяг др. ар.

Тираж екз. Заказ №

м. Дніпродзержинськ,

вул. Дніпробудівська,2.

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