Легковаговик
– шаблон проектування, який використовується
для ефективної підтримки (в першу чергу
для зменшення затрат пам'яті) великої
кількості дрібних об'єктів. Також він
використовує загальнодоступний легкий
об'єкт, який одночасно може використовуватися
у великій кількості контекстів. Стан
цього об'єкта поділяється на внутрішній,
що містить інформацію, незалежну від
контексту, і зовнішній, який залежить
або змінюється разом з контекстом легковаговика.
Об'єкти клієнтів відповідають за передачу
зовнішнього стану легковаговика, коли
йому це необхідно.
Шаблон
Легковаговик можна використовувати
коли:
- В програмі
використовується велика кількість об'єктів.
- Затрати на
збереження високі через велику кількість
об'єктів.
- Більшість
станів об'єктів можна зробити зовнішніми.
- Велика кількість
груп об'єктів може бути замінена відносно
малою кількістю загальнодоступних об'єктів,
однократно видаливши зовнішній стан.
- Програма
не залежить від ідентичності об'єктів.
Оскільки об'єкти-легковаговики можуть
використовуватися колективно, то тести
на ідентичність будуть повертати значення
"істина" ("true") для концептуально
різних об'єктів.
Шаблони
поведінки
Шаблони
поведінки — шаблони проектування, що
пов'язані з алгоритмами та розподілом
обов'язків поміж об'єктів. Мова в них йде
не тільки про самі об'єкти та класи, але
й про типові способи їхньої взаємодії.
Шаблони поведінки характеризують складний
потік керування, котрий досить важко
прослідкувати під час виконання програми.
Увага акцентована не на потоці керування,
а на зв'язках між об'єктами.
У
шаблонах поведінки рівня класу
використовується спадкування —
щоб розподілити поведінку поміж
різних класів.
У
шаблонах поведінки рівня об'єкта
використовується композиція. Деякі
з них описують, як за допомогою
кооперації багато рівноправних об'єктів
пораються із завданням, котре жодному
з них не під силу. Тут є важливим
те, як об'єкти отримують інформацію
про існування один одного. Об'єкти-колеги
можуть зберігати посилання один
на одного, але це посилює ступінь
зв'язаності системи. За максимального
рівня зв'язаності кожному об'єкту
довелось би мати інформацію про всі
інші. Деякі з наведених шаблонів
вирішують цю проблему.
Перелік
шаблонів поведінки:
- Інтерпретатор
(Interpreter);
- Ітератор
(Iterator);
- Команда (Command);
- Посередник
(Mediator);
- Спостерігач
(Observer);
- Стан (State);
- Знімок (Memento);
- Шаблонний
метод (Template Method).
Інтерпретатор
— шаблон проектування, який для заданої
мови визначає представлення її граматики,
а також інтерпретатор речень цієї мови.
У
разі, якщо якась задача виникає
досить часто, є сенс подати її конкретні
проявлення у вигляді речень простою
мовою. Потім можна буде створити
інтерпретатор, котрий вирішує задачу,
аналізуючи речення цієї мови.
Наприклад,
пошук рядків за зразком — досить
розповсюджена задача. Регулярні
вирази — це стандартна мова для
задання зразків пошуку.
Шаблон
Інтерпретатор слід використовувати,
коли є мова для інтерпретації, речення
котрої можна подати у вигляді
абстрактних синтаксичних дерев. Найкраще
шаблон працює коли:
- граматика
проста. Для складних граматик ієрархія
класів стає занадто громіздкою та некерованою.
У таких випадках краще застосовувати
генератори синтаксичних аналізаторів,
оскільки вони можуть інтерпретувати
вирази, не будуючи абстрактних синтаксичних
дерев, що заощаджує пам'ять, а можливо
і час;
- ефективність
не є головним критерієм. Найбільш ефективні
інтерпретатори зазвичай не працюють
безпосередньо із деревами, а спочатку
транслюють їх в іншу форму. Так, регулярний
вираз часто перетворюють на скінченний
автомат. Але навіть у цьому разі сам транслятор
можна реалізувати за допомогою шаблону
інтерпретатор.
Ітератор
— шаблон проектування, який надає спосіб
послідовного доступу до всіх елементів
складеного об'єкта, не розкриваючи його
внутрішнього улаштування.
Складений
об'єкт, скажімо список, повинен надавати
спосіб доступу до своїх елементів,
не розкриваючи їхню внутрішню структуру.
Більш того, іноді треба обходити
список по-різному, у залежності від
задачі, що вирішується. При цьому
немає ніякого бажання засмічувати
інтерфейс класу Список усілякими
операціями для усіх потрібних варіантів
обходу, навіть якщо їх усі можна
передбачити заздалегідь. Крім того,
іноді треба, щоб в один момент
часу існувало декілька активних операцій
обходу списку.
Все
це призводить до необхідності реалізації
шаблону Ітератор. Його основна ідея
у тому, щоб за доступ до елементів та обхід
списку відповідав не сам список, а окремий
об'єкт-ітератор. У класі Ітератор означений
інтерфейс для доступу до елементів списку.
Об'єкт цього класу прослідковує поточний
елемент, тобто він володіє інформацією,
які з елементів вже відвідувались.
Можна
використовувати шаблон Ітератор у
випадках:
- для доступу
до змісту агрегованих об'єктів не розкриваючи
їхнє внутрішнє улаштування;
- для підтримки
декількох активних обходів одного й того
ж агрегованого об'єкта;
- для подання
уніфікованого інтерфейсу з метою обходу
різноманітних агрегованих структур (тобто
для підтримки поліморфної ітерації).
Команда
— шаблон проектування, який інкапсулює
запит у формі об'єкта, дозволяючи тим
самим задавати параметри клієнтів для
обробки відповідних запитів, ставити
запити у чергу або протоколювати їх, а
також підтримувати скасовування операцій.
Слід
використовувати шаблон Команда
коли:
- треба параметризувати
об'єкти дією. У процедурній мові таку
параметризацію можна виразити за допомогою
функції оберненого виклику, тобто такою
функцією, котра реєструється, щоби бути
викликаною пізніше. Команди є об'єктно-орієнтованою
альтернативою функціям оберненого виклику;
- визначати,
ставити у чергу та виконувати запити
у різний час. Строк життя об'єкта Команди
не обов'язково залежить від строку життя
початкового запиту. Якщо отримувача вдається
реалізувати таким чином, щоб він не залежав
від адресного простору, то об'єкт-команду
можна передати іншому процесу, котрий
займеться його виконанням;
- потрібна
підтримка скасовування операцій. Операція
Execute об'єкта Команда може зберегти стан,
що необхідний для відкочення дій, виконаних
Командою. У цьому разі у інтерфейсі класу
Command повинна бути додаткова операція
Unexecute, котра скасовує дії, виконанні попереднім
викликом операції Execute. Виконані команди
зберігаються у списку історії. Для реалізації
довільної кількості рівней скасування
та повтору команд треба обходити цей
список відповідно в оберненому та прямому
напрямках, викликаючи під час відвідування
кожного елементу операцію Unexecute або Execute;
- підтримати
протоколювання змін, щоб їх можна було
виконати повторно після аварійної зупинки
системи. Доповнивши інтерфейс класу Command
операціями зберігання та завантаження,
можна вести протокол змін у внутрішній
пам'яті. Для поновлення після збою треба
буде завантажити збереженні команди
з диску та повторно виконати їх за допомогою
операції Execute;
- треба структурувати
систему на основі високорівневих операцій,
що побудовані з примітивних. Така структура
є типовою для інформаційних систем, що
підтримують трансакції. Трансакція інкапсулює
множину змін даних. Шаблон Команда дозволяє
моделювати трансакції. В усіх команд
є спільний інтерфейс, що надає можливість
працювати однаково з будь-якими трансакціями.
За допомогою цього шаблону можна легко
додавати у систему нові види трансакцій.
Посередник
– шаблон проектування, який визначає
об'єкт, що інкапсулює спосіб взаємодії
множини об'єктів. Посередник забезпечує
слабку зв'язаність системи, звільняючи
об'єкти від необхідності явно посилатися
один на одного, і дозволяючи тим самим
незалежно змінювати взаємодії між ними.
Слід
використовувати шаблон Посередник
у випадках, коли:
- існують об'єкти,
зв'язки між котрими досить складні та
чітко задані. Отримані при цьому залежності
не структуровані та важкі для розуміння;
- не можна
повторно використовувати об'єкт, оскільки
він обмінюється інформацією з багатьма
іншими об'єктами;
- поведінка,
розподілена між кількома класами, повинна
піддаватися налагодженню без створювання
множини підкласів.
Спостерігач
– шаблон проектування, який визначає
залежність типу «один до багатьох» між
об'єктами таким чином, що при зміні стану
одного об'єкта всі залежних від нього
сповіщаються про цю подію.
Шаблон
«спостерігач» застосовується в
тих випадках, коли система володіє
такими властивостями:
- існує, як
мінімум, один об'єкт, що розсилає повідомлення
- є не менше
одного одержувача повідомлень, причому
їхня кількість і склад можуть змінюватися
під час роботи програми.
Цей
шаблон часто застосовують в ситуаціях,
в яких відправника повідомлень
не цікавить, що роблять одержувачі
з наданою їм інформацією.
Стан
— шаблон проектування, який дозволяє
об'єктові варіювати свою поведінку у
залежності від внутрішнього стану. Ззовні
здається, що змінився клас об'єкта.
Слід
використовувати шаблон Стан у випадках,
коли:
- поведінка
об'єкта залежить від його стану та повинно
змінюватись під час виконання програми;
- у коді операцій
зустрічаються умовні оператори, що складаються
з багатьох частин, у котрих вибір гілки
залежить від стану. Зазвичай у такому
разі стан представлено константами, що
перелічуються. Часто одна й та ж структура
умовного оператору повторюється у декількох
операціях. Шаблон Стан пропонує помістити
кожну гілку у окремий клас. Це дозволить
трактувати стан об'єкта як самостійний
об'єкт, котрий можна змінитися незалежно
від інших.
Знімок
— шаблон проектування, який не порушуючи
інкапсуляції, фіксує та виносить за межі
об'єкта його внутрішній стан так, щоб
пізніше можна було відновити з нього
об'єкт.
Слід
використовувати шаблон Знімок у
випадках, коли:
- необхідно
зберегти миттєвий знімок стану об'єкта
(або його частини), щоб згодом об'єкт можна
було відтворити у тому ж самому стані;
- безпосереднє
вилучення цього стану розкриває деталі
реалізації та порушує інкапсуляцію об'єкта.
Шаблонний
метод – шаблон проектування, який визначає
основу алгоритму та дозволяє підкласам
перевизначити деякі кроки алгоритму,
не змінюючи структуру в цілому.
Слід
використовувати шаблон Шаблонний
метод коли:
- треба одноразово
використати інваріантні частини алгоритму,
залишаючи реалізацію поведінки, що змінюється,
на розсуд підкласів;
- треба відокремити
та локалізувати в одному класі поведінку,
що є загальною для усіх підкласів, щоб
запобігти дублювання коду. Це хороший
приклад техніки “винесення за лапки
з метою узагальнення”, що описана у роботі
Вільяма Опдайка та Ральфа Джонсона. Спочатку
ідентифікуються відмінності в існуючому
коді, а потім вони виносяться у окремі
операції. У кінцевому підсумку відмінні
фрагменти коду замінюються шаблонним
методом, з котрого викликаються нові
операції;
- для управління
розширеннями підкласів. Можна визначити
шаблонний метод таким чином, що він буде
викликати операції-зачіпки у означених
точках, дозволивши тим самим розширення
тільки у цих точках.
Висновки
Отже,
шаблони проектування програмного забезпечення
є дійсно ефективними способами вирішення
задач проектування програмного забезпечення.
Їх можна застосовувати при проектуванні
програм, використовуючи виведені Бандою
чотирьох шаблони.
Список
використаної літератури
- Алан Шаллоуей,
Джеймс Р. Тротт Шаблоны проектирования.
Новый подход к объектно-ориентированному
анализу и проектированию = Design Patterns Explained:
A New Perspective on Object-Oriented Design. — М. : «Вильямс»,
2002.
- http://uk.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B8_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B7%D0%B0%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%BD%D1%8F
- http://uk.wikipedia.org/wiki/%D0%A2%D0%B2%D1%96%D1%80%D0%BD%D1%96_%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B8
- http://uk.wikipedia.org/wiki/%D0%A1%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%BD%D1%96_%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B8
- http://uk.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B8_%D0%BF%D0%BE%D0%B2%D0%B5%D0%B4%D1%96%D0%BD%D0%BA%D0%B8