Відносини учасників паттерна. 1. Зазвичай, під час виконання створюється єдиний екземпляр класу ConcreteFactory

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

2. AbstractFactory передоручає створення об’єктів-продуктів своєму підкласу ConcreteFactory.

3. Клієнт знає тільки про існування абстрактної фабрики й абстрактних продуктів.

Результати використання. Паттерн Абстрактна фабрика має наступні плюси й мінусами:

1. Ізолює конкретні класи. Допомагає контролювати класи об’єктів, що створюються додатком. Оскільки фабрика інкапсулює відповідальність за створення класів і сам процес їхнього створення, то вона ізолює клієнта від деталей реалізації класів. Клієнти маніпулюють екземплярами через їхні абстрактні інтерфейси. Імена створюваних класів відомі тільки конкретній фабриці, у коді клієнта вони не згадуються.

2. Спрощує заміну сімейств продуктів. Клас конкретної фабрики з’являється в додатку тільки один раз: при інстанціюванні. Це полегшує заміну використовуваної додатком конкретної фабрики. Додаток може змінити конфігурацію продуктів, просто підставивши нову конкретну фабрику. Оскільки абстрактна фабрика створює все сімейство продуктів, то й заміняється відразу все сімейство.

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

4. Підтримати новий вид продуктів важко. Розширення абстрактної фабрики для виготовлення нових видів продуктів – непросте завдання. Інтерфейс AbstractFactory фіксує набір продуктів, які можна створити. Для підтримки нових продуктів необхідно розширити інтерфейс фабрики, тобто змінити клас AbstractFactory і всі його підкласи.

Паттерн Прототип (Prototype)

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

Частота використання

Мотивація застосування. Цей паттерн надає об’єкти за допомогою прототипу та дозволяє створювати нові об’єкти в обхід ключового слова new та конструктора, використовуючи замість цього просте копіювання. Як правило, до паттерна Прототип треба вдаватися у тому випадку, коли [23]:

- клієнтський код повинен створювати об’єкти, нічого не знаючи про їх клас, або про те, які дані вони містять;

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

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

Проблемні предметні області.

1. Можливо використовувати цей дизайн-паттерн для копіювання екземплярів об’єктів підчас виконання програми, що дозволяє уникати великої кількості похідних класів. Для прикладу: замість того, щоб мати такі класи як «п’ятиповерхова будівля із трикімнатними квартирами», «дев’ятиповерхова будівля із 2…4-кімнатними квартирами» і «дванадцятиповерхова будівля із 1…3-кімнатними квартирами», можливо мати просто три екземпляри класу ApartmentBlock, які ініціалізовані вже з потрібними властивостями, а потім просто скопіювати один із екземплярів, коли будівельній компанії потрібно збудувати якийсь конкретний будинок десь в місті. Іншими словами, можливо обійтися без написання подібного [15]:

new ApBlockWith9FloorsAnd234Flats()

або

new ApartmentBlock(){Floors = 9; FlatsDic = {2,3,4}}

Все, чого буде достатньо – це _9FloorsApBlock.Clone (). Зазвичай, можна поєднувати цей патерн із Фабричним Методом – таким чином маємо схожий на GetMe9FloorsAppBlock() метод, який всередині буде викликати копіювання прототипічного екземпляру.

2. Припустимо, що стоїть завдання розробити гру «Тетріс», зокрема, «Будівництво». З верхньої частини ігрової області падають будівельні блоки різної форми. Завдання гравця полягає в тому, щоб не дозволити будівельним блокам заповнити всю ігрову область знизу вгору. Для цього треба намагатися розташовувати блоки так, щоб повністю заповнити горизонтальну лінію, оскільки повністю заповнені лінії зникають.

Набір різних форм будівельних блоків фіксований. Програма випадковим чином вибирає форму подальшого будівельного блоку, створює блок у відповідність з обраною формою і починає просувати її по ігровому полю. Маємо наступне питання. Як створювати екземпляри будівельних блоків, мінімізувавши при цьому залежність клієнтського коду від типу форми блоку?Можна запропонувати наступне рішення. Нехай кожен об’єкт будівельного блоку вміє створювати копію самого себе через якийсь універсальний інтерфейс. У програмі є список блоків-прототипів, кожен з яких представляє одну з можливих форм. При необхідності створення такого блоку його прототип випадковим чином вибирається зі списку, після чого створюється новий примірник будівельного блоку за допомогою клонування обраного прототипу. Оскільки передбачений універсальний інтерфейс для клонування, то клієнтський код повністю не залежить від того, будівельний блок якої форми йому треба клонувати.

Структура паттерну наведена на рисунку 4.2.

Поиск по сайту: