Учасники паттерна. - оголошує інтерфейс для клонування самого себе (у мові C# для таких цілей можна використовувати стандартний інтерфейс ICloneable)

1. Prototype – прототип:

- оголошує інтерфейс для клонування самого себе (у мові C # для таких цілей можна використовувати стандартний інтерфейс ICloneable).

2. ConcretePrototype – конкретний прототип:

- реалізує операцію клонування самого себе.

3. Client – клієнт:

- створює новий об’єкт, звертаючись до прототипу із запитом клонувати себе.

Рис. 4.2. Діаграма класів паттерна Прототип

Відносини учасників паттерна. Клієнт звертається до прототипу, щоб той створив свою копію.

Особливості програмної реалізації [12].

1. Використання диспетчера прототипів. Якщо кількість прототипів у системі не фіксована (тобто вони можуть створюватися і знищуватися динамічно), необхідно вести реєстр доступних прототипів. Клієнти повинні не керувати прототипами самостійно, а зберігати і витягати їх з реєстру. Клієнт запитує прототип з реєстру перед його клонуванням. Такий реєстр називається диспетчером прототипів. Диспетчер прототипів - це асоціативне сховище, що повертає прототип, який відповідає заданому ключу. В ньому є операції для реєстрації прототипу з зазначеним ключем і скасування реєстрації. Клієнти можуть змінювати і навіть переглядати реєстр під час виконання, а виходить, і розширювати систему і вести контроль над її станом без написання коду.

2. Реалізація операції Clone. Сама важка частина паттерна Прототип – правильна реалізація операції Clone. Особливо складно це у випадку, коли в структурі об’єкта є кругові посилання. У більшості мов мається деяка підтримка для клонування об’єктів. Але ці засоби не вирішують проблему глибокого і поверхневого копіювання. Суть проблеми в наступному: чи повинні при клонуванні об’єкта клонуватися також і його змінні екземпляра або клон просто розділяє з оригіналом ці змінні? Поверхневе копіювання просте, і часто його буває досить. Але для клонування прототипів зі складною структурою зазвичай необхідно глибоке копіювання, оскільки клон повинний бути незалежний від оригіналу. Тому потрібно гарантувати, що компоненти клону є клонами компонентів прототипу. При клонуванні приходиться вирішувати, що саме може розділятися та чи може взагалі.

3. Ініціалізація клонів. Хоча деяким клієнтам цілком достатньо клону як такого, іншим потрібно ініціалізувати його внутрішній стан цілком або частково. Зазвичай передати початкові значення операції Clone неможливо, оскільки їхня кількість різна для різних класів прототипів. Для деяких прототипів потрібно багато параметрів ініціалізації, інші взагалі нічого не вимагають. Передача Clone параметрів заважає побудові однакового інтерфейсу клонування. Може виявитися, що у класах прототипів уже визначаються операції для установки й очищення деяких важливих елементів стану. Якщо так, то цими операціями можна скористатися відразу після клонування. У протилежному випадку, можливо, знадобиться ввести операцію Іnіtіalіze, що приймає початкові значення як аргументи і відповідно установлює внутрішній стан клону. Будьте обережні, якщо операція Clone реалізує глибоке копіювання: копії може знадобитися видаляти (явно або усередині Іnіtіalіze) перед повторною ініціалізацією.

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

1. Додавання/видалення нових типів продуктів під час виконання. Об’єкти-прототипи можна створювати і видаляти на етапі виконання. Таке рішення представляє більшу гнучкість у порівнянні з Abstract Factory або Factory Method.

2. Визначення нових типів продуктів без необхідності спадкування.Для створення нового типу продукту треба визначити його прототип, що, в загальному випадку, не вимагає спадкування. Це, найчастіше, дозволяє позбавитися від великих ієрархій класів, які потрібні при використанні паттернів Abstract Factory або Factory Method.

3. Використання диспетчера прототипів. Найчастіше для управління прототипами в системі використовується спеціальний диспетчер, в якому реєструються прототипи. Клас-диспетчер дозволяє отримувати необхідний прототип за його ім’ям, а також динамічно додавати або видаляти прототипи. Відсутність параметрів у методі Clone() забезпечує найбільш загальний інтерфейс для клонування. Основний недолік паттерну прототип полягає в тому, що кожен підклас класу Prototype повинен реалізовувати операцію Clone, а це далеко не завжди просто. Наприклад, складно додати операцію Clone, коли класи, що розглядаються, вже існують. Проблеми виникають і у випадку, якщо у внутрішньому поданні об’єкта є інші об’єкти або наявні кругові посилання.

4. Специфікація нових об’єктів шляхом зміни значень. Динамічні системи дозволяють визначити поведінки за рахунок композиції об’єктів – наприклад шляхом завдання значень змінних об’єкта – а не за допомогою нових класів. По суті, використання паттерну дозволяє визначати нові класи без програмування. Фактично клонування об’єкту аналогічно створенню екземпляра класу. А використання паттерна може різко зменшити загальну кількість необхідних класів.

Паттерн Одинак (Singleton)

Призначення. Одинак – це породжувальний паттерн, який гарантує, що в класі є лише один примірник, та надає до нього глобальну точку доступу [12,17].

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

Мотивація застосування. Часто в програмуванні трапляється ситуація, коли треба визначити деяку змінну, яка доступна глобально і може існувати тільки в одному примірнику. Наприклад, для доступу в систему бухгалтерського обліку організації користувачу необхідно пройти аутентифікацію, вказавши своє ім’я і пароль. Після успішної аутентифікації користувач отримує доступ до системи. При цьому в кожний момент часу системі повинні бути відомі персональні дані користувача: його повне ім’я, рівень доступу і, можливо, інші дані. Для реалізації такої можливості слід визначити деякий об’єкт, який доступний з кожної точки системи (наприклад, для визначення того, чи є доступ користувача до певних можливостей системи) і може існувати тільки в одному примірнику (оскільки одночасно в системі не можуть аутентифікуватися двоє і більше користувачів). Існує багато об’єктів, що потрібні тільки в одному екземплярі: пули програмних потоків, кеші, діалогові вікна, об’єкти ведення журналу, об’єкти драйверів пристроїв. Більш того, для багатьох типів таких об’єктів спроба створення більш одного екземпляра приведе до всіляких проблем – некоректному поводженню програми, зайвим витратам ресурсів або нелогічним результатам.

У мові C ++ це можна реалізувати за допомогою використання глобальної змінної або статичного поля класу. Але такий підхід має недоліки:

- клієнтський код має вільний доступ до цієї змінної, що може призвести до її несанкціонованим змінам;

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

Слід зазначити, що в повністю об’єктно-орієнтованих мовах, якими є C # і Java, зовсім виключена можливість визначення глобальних змінних, тому в таких мовах для визначення глобального стану можна використовувати тільки статичні поля класу. Більш вдале рішення – сам клас контролює те, що у нього є лише один примірник, може заборонити створення додаткових примірників, перехоплюючи запити на створення нових об’єктів, і він же здатний надати доступ до свого екземпляру. Це і є призначення паттерну одинака. У разі роботи з паттерном Singleton сам клас контролює наявність єдиного свого примірника і надає доступ до нього. Паттерн Одинак використовується, коли:

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

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

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

Для подолання недоліків поданої ідеї скористаємося таким підходом, що реалізується в паттерні Singleton [21]:

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

- доступ до свого єдиного примірника також повинен надавати сам клас;

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

Технічна реалізація запропонованого підходу може виглядати так:

- для заборони створення екземплярів класу зовнішнім кодом його конструктор (або конструктори) визначаються як protected;

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

- члени класу єдиного примірника (крім змінної, в якій зберігається посилання на єдиний об’єкт, і методи надання доступу до цієї змінної) повинні бити нестатичними. Це дозволить, при потребі, модифікувати поведінку класу, успадковував від нього підкласи.

Загальна схема паттерна Одинак представлена засобами діаграми класів на рисунку 4.3.

Рис. 4.3. Діаграма класів паттерна Одинак

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