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

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

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

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

нафти і газу  
 
 
 
 
 
 
 
 
 
 
 

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

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

Виконала:

Студентка групи ПМ-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 широко використовують шаблон Декоратор для організації обробки операцій введення-виведення.

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

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

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

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

 

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

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

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

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