Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

Шаблони проектування програмного забезпечення

Міністерство освіти і науки, молоді та спорту України

Коледж електронних приладів

Івано-Франківського національного технічного університету

нафти і газу

Реферат на тему:

Шаблони проектування програмного забезпечення

Виконала:

Студентка групи ПМ-41

Мінтяник О.Р.

Перевірив:

Левицький І.В

Івано-Франківськ

2011

Вступ

Шаблони проектування програмного забезпечення — ефективні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення.

У 70-х роках двадцятого сторіччя архітектор Кристофер Александр склав перелік шаблонів проектування. В області архітектури ця ідея не отримала такого розвитку, котрого вона досягла пізніше в області розробки програмного забезпечення.

У 1987 році Кент Бек і Вард Каннігем узяли ідеі Крістофер Александра та розробили шаблони відповідно до розробки програмного забезпечення для розробки графічних оболонок мовою Smalltalk.

У 1988 році Ерік Ґамма почав писати докторську роботу при цюрихському університеті про загальну переносимість цієї методики на розробку програм.

У 1989—1991 роках Джеймс Коплін трудився над розробкою ідіом для програмування мовою C++ та опублікував у 1991 році книгу «Advanced C++ Idioms».

У цьому ж році Ерік Ґамма закінчує свою докторську роботу та переїздить до США, де у співробітництві з Річардом Хелмом, Ральфом Джонсоном та Джоном Вліссідсом публікує книгу «Design Patterns — Elements of Reusable Object-Oriented Software». У цій книзі описані 23 шаблона проектування. Також команда авторів цієї книги відома суспільству під назвою Банда чотирьох. Саме ця книга послужила привідом до прориву методу шаблонів.

Є такі три типи шаблонів проектування програмного забезпечення:

Твірні шаблони;
Структурні шаблони;
Шаблони поведінки.

Твірні шаблони

Твірні шаблони — це шаблони проектування, що абстрагують процес інстанціювання. Вони допоможуть зробити систему незалежною від способу створення, композиції та представлення її об'єктів.

Шаблон, який породжує класи, використовує спадкування, щоб варіювати створюваний клас, а шаблон, що створює об'єкти, делегує інстанціювання іншому об'єктові.

Ці шаблони важливі, коли система більше залежить від композиції об'єктів, ніж від спадкування класів.

Перелік твірних шаблонів:

Абстрактна фабрика (Abstract Factory);
Будівник (Builder);
Одинак (Singleton);
Прототип (Prototype);
Фабричний метод (Factory Method).

Абстрактна фабрика — шаблон проектування, який подає інтерфейс для утворення родин взаємозв'язаних або взаємозалежних об'єктів, не специфікуючи їхніх конкретних класів.

Слід використовувати шаблон Абстрактна фабрика коли:

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

Будівник — шаблон проектування, який відокремлює конструювання складного об'єкта від його подання, таким чином у результаті одного й того ж процесу конструювання можуть бути отримані різні подання.

Слід використовувати шаблон Будівник коли:

алгоритм створення складного об'єкта не повинен залежати від того, з яких частин складається об'єкт та як вони стикуються поміж собою;
процес конструювання повинен забезпечити різні подання об'єкта, що конструюється.

Одинак — шаблон проектування, який гарантує, що клас матиме тільки один екземпляр, і забезпечує глобальну точку доступу до цього екземпляра.

Для деяких класів важливо, щоб існував тільки один екземпляр. Наприклад, хоча у системі може існувати декілька принтерів, може бути тільки один спулер. Повинна бути тільки одна файлова система та тільки один активний віконний менеджер.

Глобальна змінна не вирішує такої проблеми, бо не забороняє створити інші екземпляри класу.

Рішення полягає в тому, щоб сам клас контролював свою «унікальність», забороняючи створення нових екземплярів, та сам забезпечував єдину точку доступу. Це є призначенням шаблону Одинак.

Слід використовувати шаблон Одинак коли:

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

Прототип – шаблон проектування, який задає види об'єктів, що створюються, за допомогою екземпляру-прототипу, та створює нові об'єкти шляхом копіювання цього прототипу.

Слід використовувати шаблон Прототип коли:

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

Фабричний метод — шаблон проектування, який визначає інтерфейс для створення об'єкта, але залишає підкласам рішення про те, який саме клас інстанціювати. Фабричний метод дозволяє класу делегувати інстанціювання підкласам.

Слід використовувати шаблон Фабричний метод коли:

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

Структурні шаблони

Структурні шаблони — шаблони проектування, у яких розглядається питання про те, як із класів та об'єктів утворюються більші за розмірами структури.

Структурні шаблони рівня класу використовують спадковість для утворення композицій із інтерфейсів та реалізацій.

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

Перелік структурних шаблонів:

Адаптер (Adapter);
Декоратор (Decorator);
Замісник (Proxy);
Міст (Bridge);
Легковаговик (Flyweight).

Адаптер — шаблон проектування, призначений для організації використання функцій об'єкта, недоступного для модифікації, через спеціально створений інтерфейс.

Адаптує інтерфейс одного класу в інший, очікуваний клієнтом. Адаптер забезпечує роботу класів з несумісними інтерфейсами, та найчастіше застосовується тоді, коли система підтримує необхідні дані і поведінку, але має невідповідний інтерфейс.

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

Типовим прикладом використання шаблону Адаптер можна назвати створення класів, що приводять до єдиного інтерфейсу функції мови PHP що забезпечують доступ до різних СУБД.

Декоратор — шаблон проектування, призначений для динамічного підключення додаткових можливостей до об'єкта. Шаблон Декоратор надає гнучку альтернативу методу визначення підкласів з метою розширення функціональності.

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

Базові класи мови Java широко використовують шаблон Декоратор для організації обробки операцій введення-виведення.

Замісник — шаблон проектування, який надає об'єкт, що контролює доступ, перехоплюючи всі виклики до нього.

Існує проблема: необхідно управляти доступом до об'єкта так, щоб створювати громіздкі об'єкти «на вимогу». Її вирішенням є створення сурогата громіздкого об'єкта. «Заступник» зберігає посилання, яке дозволяє заступникові звернутися до реального суб'єкта. Оскільки інтерфейс «Реального Суб'єкта» ідентичний інтерфейсу «Суб'єкта», так, що «Заступника» можна підставити замість «Реального Суб'єкта», контролює доступ до «Реального Суб'єкта», може відповідати за створення або видалення «Реального Суб'єкта». «Суб'єкт» визначає загальний для «Реального Суб'єкта» і «Заступника» інтерфейс, так, що «Заступник» може бути використаний скрізь, де очікується «Реальний Суб'єкт».

«Заступник» може мати і інші обов'язки, а саме:

видалений «Заступник» може відповідати за кодування запиту і його аргументів і відправку закодованого запиту реальному «Суб'єктові»
віртуальний «Заступник» може кешувати додаткову інформацію про реального «Суб'єкта», щоб відкласти його створення
захищаючий «Заступник» може перевіряти, чи має зухвалий об'єкт необхідні для виконання запиту має рацію.

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

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

Слід використовувати шаблон Міст у випадках, коли:

треба запобігти постійній прив'язці абстракції до реалізації. Так, наприклад, буває коли реалізацію необхідно обрати під час виконання програми;
як абстракції, так і реалізації повинні розширюватись новими підкласами. У цьому разі шаблон Міст дозволяє комбінувати різні абстракції та реалізації та змінювати їх незалежно одне від одного;
зміни у реалізації не повинні впливати на клієнтів, тобто клієнтський код не повинен перекомпілюватись;
треба повністю сховати від клієнтів реалізацію абстракції;
треба розподілити одну реалізацію поміж кількох об'єктів (можливо застосовуючи підрахунок посилань), і при цьому приховати це від клієнту.

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

Шаблон Легковаговик можна використовувати коли:

В програмі використовується велика кількість об'єктів.
Затрати на збереження високі через велику кількість об'єктів.
Більшість станів об'єктів можна зробити зовнішніми.
Велика кількість груп об'єктів може бути замінена відносно малою кількістю загальнодоступних об'єктів, однократно видаливши зовнішній стан.
Програма не залежить від ідентичності об'єктів. Оскільки об'єкти-легковаговики можуть використовуватися колективно, то тести на ідентичність будуть повертати значення "істина" ("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

Шаблони проектування програмного забезпечення