Шаблон «Абстрактна фабрика» (Abstract Factory)
Назва та класифікація
Абстрактна фабрика — шаблон, що породжує об’єкти.
Призначення
Надає інтерфейс для створення сімейств взаємопов’язаних чи взаємозалежних об’єктів, не специфікуючи їх конкретних класів.
Інші назви
Інструментарій (Kit).
Підстави для застосування
1. Система не повинна залежати від того, як створюються, компонуються та представляються об’єкти, що в неї входять.
2. Взаємопов’язані об’єкти повинні використовуватися разом і потрібно це обмеження забезпечити.
3. Система повинна конфігуруватися одним із сімейств об’єктів, що входять в неї.
4. Потрібно створити бібліотеку об’єктів, розкриваючи тільки їхні інтерфейси, але не реалізацію.
Структура
Учасники
1. AbstractFactory — абстрактна фабрика:
- описує інтерфейс для операцій, що створюють абстрактні об’єкти-продукти.
2. ConcreteFactory — конкретна фабрика:
- реалізує операції, що створюють абстрактні об’єкти-продукти.
3. AbstractProduct — абстрактний продукт:
- описує інтерфейс для типу об’єкта-продукту.
4. ConcreteProduct —конкретний продукт:
- визначає об’єкт-продукт, створюваний відповідною абстрактною фабрикою;
- реалізує інтерфейс AbstractProduct.
5. Client — клієнт:
- користується виключно інтерфейсами, які описані в класах AbstractFactory та AbstractProduct.
Відношення
1. Зазвичай під час виконання створюється єдиний екземпляр класу ConcreteFactory. Ця конкретна фабрика створює об’єкти-продукти, що мають цілком визначену реалізацію. Для створення інших видів об’єктів клієнт повинен використати іншу конкретну фабрику.
2. AbstractFactory делегує створення об’єктів-продуктів своєму підкласу ConcreteFactory.
Результати
1. (+) Ізолює конкретні класи.
2. (+) Спрощує заміну сімейств продуктів.
3. (+) Гарантує сумісність продуктів.
4. (–) Складно підтримати новий вид продуктів.
Шаблон «Будівельник» (Builder)
Назва та класифікація
Будівельник — шаблон, що породжує об’єкти.
Призначення
Відділяє конструювання складного об’єкта від його представлення. Таким чином в результаті одного й того ж процесу конструювання можуть виходити різні представлення.
Підстави для застосування
1. Алгоритм створення складного об’єкта не повинен залежати від того, із яких частин складається об’єкт, і як ці частини між собою організовані.
2. Процес конструювання повинен забезпечувати різноманітні представлення об’єкта, що конструюється.
Структура
Учасники
1. Builder — абстрактний будівельник:
- задає абстрактний інтерфейс для створення частин об’єкта Product.
2. ConcreteBuilder — конкретний будівельник:
- конструює та збирає разом частини продукту (шляхом реалізації інтерфейсу Builder);
- визначає створюване представлення та слідкує за ним;
- надає інтерфейс для доступу до продукту.
3. Director — розпорядник:
- конструює об’єкт, користуючись інтерфейсом Builder.
4. Product — продукт:
- представляє складний об’єкт. ConcreteBuilder будує внутрішнє представлення продукту та визначає процес його збірки;
- включає в себе класи, які визначають складові частини продукту, в тому числі інтерфейси для збору кінцевого результату із частин.
Відношення
1. Клієнт створює об’єкт-розпорядник Director та конфігурує його потрібним об’єктом-будівельником Builder.
2. Розпорядник повідомляє будівельника про те, що потрібно побудувати наступну частину продукту.
3. Будівельник обробляє запити розпорядника і додає нові частини до продукту.
4. Клієнт забирає продукт в будівельника.
Загальна схема дій виглядає таким чином:
Результати
1. (+) Дозволяє змінювати внутрішнє представлення продукту.
2. (+) Ізолює код, який реалізує конструювання та представлення.
3. (+) Дає більш тонкий контроль над процесом конструювання.