Одинак (шаблон проектування)

План

1. Поняття шаблону проектування програмного забезпечення.

2. Історія розвитку шаблонів проектування.

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

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

5. Шаблони поведінки.

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

2. Історія

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

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

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

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

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

1.	Твірні шаблони	Абстрактна фабрика (Abstract Factory) • Будівник (Builder) • Одинак (Singleton) • Прототип (Prototype) • Фабричний метод (Factory Method)
2.	Структурні шаблони	Адаптер (Adapter) • Декоратор (Decorator) • Замісник (Proxy) • Компонувальник (Composite) • Міст (Bridge) • Легковаговик (Flyweight) • Фасад (Facade)
3.	Шаблони поведінки	Відвідувач (Visitor) • Інтерпретатор (Interpreter) • Ітератор (Iterator) • Команда (Command) • Ланцюжок відповідальностей (Chain of Responsibility) • Посередник (Mediator) • Спостерігач (Observer) • Стан (State) • Стратегія (Strategy) • Знімок (Memento) • Шаблонний метод (Template Method)

Архітектурні шаблони програмного забезпечення

4.	Архітектурні шаблони програмного забезпечення
		Модель-вид-контролер
		Представлення-абстракція-управління	Матеріал відсутній
		Клієнт-серверна архітектура
		Три-ярусна архітектура	Матеріал відсутній
		Сервісно-орієнтована архітектура
		Active Record	шаблон проектування що використовується при реалізації доступу до реляційних баз даних.

Архітектурні шаблони програмного забезпечення (англ. Software architectural patterns) — це шаблони програмного забезпечення, що являють собою звіт «добрих практик» (англ. good practices) вирішення архітектурних проблем розробки програмного забезпечення. Архітектурні шаблони виражають фундаментальну схему структурної організації певної програмної системи. Така схема складається із визначених наперед підсистем, а також точно визначає їхні сфери відповідальності та взаємовідносини.

Порівняння із шаблонами проектування

На відміну від шаблонів проектування, архітектурні шаблони мають ширший масштаб. Основними елементами структури архітектурних шаблонів є не класи й об'єкти, а умовні частини (підсистеми) програмної системи.

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

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

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

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

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

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

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

Єдина інформація про об'єкти, що відома системі — їхні інтерфейси.

Абстрактна фабрика

Абстрактна фабрика (англ. Abstract Factory) — шаблон проектування, відноситься до класу твірних шаблонів.

Призначення

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

Мотивація

Застосування

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

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

Структура

UML діаграма, що описує структуру шаблону проектування Абстрактна фабрика

• AbstractFactory — абстрактна фабрика:
• оголошує інтерфейс для операцій, що створюють абстрактні об'єкти-продукти;

• ConcreteFactory — конкретна фабрика:
• реалізує операції, що створюють конкретні об'єкти-продукти;

• AbstractProduct — абстрактний продукт:
• оголошує інтерфейс для типу об'єкта-продукту;

• ConcreteProduct — конкретний продукт:
• визначає об'єкт-продукт, що створюється відповідною конкретною фабрикою;
• реалізує інтерфейс AbstractProduct;

• Client — клієнт:
• користується виключно інтерфейсами, котрі оголошенні у класах AbstractFactory та AbstractProduct.

Відносини

• Зазвичай під час виконання створюється єдиний екземпляр класу ConcreteFactory. Ця конкретна фабрика створює об'єкти продукти, що мають досить визначену реалізацію. Для створення інших видів об'єктів клієнт повинен користуватися іншою конкретною фабрикою;
• AbstractFactory передоручає створення об'єктів продуктів своєму підкласу ConcreteFactory.

Реалізація

3.2. Будівник (шаблон проектування)

Будівник (англ. Builder) — шаблон проектування, відноситься до класу твірних шаблонів.

Призначення

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

Мотивація

Застосування

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

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

Структура

UML діаграма, що описує структуру шаблону проектування Будівник

• Builder — будівник:
• визначає абстрактний інтерфейс для створення частин об'єкта Product;
• ConcreteBuilder — конкретний будівник:
• конструює та збирає докупи частини продукту шляхом реалізації інтерфейсу Builder;
• визначає подання, що створюється, та слідкує на ним;
• надає інтерфейс для доступу до продукту;
• Director — управитель:
• конструює об'єкт, користуючись інтерфейсом Builder;
• Product — продукт:
• подає складний конструйований об'єкт. ConcreteBuilder будує внутрішнє подання продукту та визначає процес його зборки;
• вносить класи, що визначають складені частини, у тому числі інтерфейси для зборки кінцевого результату з частин.

Відносини

• клієнт створює об'єкт-управитель Director та конфігурує його потрібним об'єктом-будівником Builder;
• управитель повідомляє будівника про те, що потрібно побудувати наступну частину подукту;
• будівник оброблює запити управителя та додає нові частини до продукту;
• клієнт забирає продукт у будівника.

UML діаграма, що описує взаємовідносини між будівником та клієнтом

Реалізація

Одинак (шаблон проектування)

Одинак (англ. Singleton) — шаблон проектування, відноситься до класу твірних шаблонів.

Призначення

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

Мотивація

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

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

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

Застосування

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

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

Структура

Діаграма класів, що описує структуру шаблону проектування Одинак

• Singleton — одинак:
• визначає операцію Instance, котра дозволяє клієнтам отримувати доступ до єдиного екземпляру. Instance — це операція класу;
• може нести відповідальність за створення власного унікального екземпляру.

Відносини

Клієнти отримують доступ до єдиного об'єкта класу Singleton лише через його операцію Instance.

Реалізації