Учасники партерна

1. Singleton – одинак:

- забезпечує створення тільки одного екземпляра самого себе, посилання на який збережеться в статичній змінній класу з ім’ям unіqueіnstance, що містить єдиний екземпляр Sіngleton;

- містить статичний метод getІnstance, що дозволяє легко викликати його в будь-якому місці з використанням синтаксису Sіngleton.getІnstancе(). Цей спосіб нітрохи не складніший за звертання до глобальної змінної, але він має додаткові переваги, такі як відкладена ініціалізація;

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

Відносини учасників паттерна. Клієнти отримують доступ до екземпляру класу Singleton тільки через його метод getInstance().

Особливості програмної реалізації. Програмним шляхом паттерн Одинак можна реалізувати наступним чином:

- статичним екземпляром класу;

- статичним методом, що створює екземпляр класу.

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

Класична реалізація паттерна Одинак припускає наявність:

- статичної змінної для збереження єдиного екземпляра класу;

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

- реалізації статичного методу, що створює і повертає екземпляр.

Використання Одинака представляє більш гнучкі можливості, ніж статичні функції класів або статичні класи C #, тому що такі програмні конструкції, як правило, володіють рядом обмежень, що роблять не можливим визначення віртуальних функцій з наступним заміщенням їх у підкласах. Використання глобальних змінних і Одинака сприяє створенню інтерфейсів, що «брешуть», тобто інтерфейсів, що не показують явних залежностей з іншими необхідними для його функціонування об’єктами.

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

Результати використання. У паттерна Одинак є певні переваги:

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

- зменшення кількості імен. Паттерн Одинак – крок вперед у порівнянні з глобальними змінними. Він дозволяє уникнути засмічення простору імен глобальними змінними, в яких зберігаються унікальні екземпляри. Досить легко створювати і підкласи від класу, що реалізує Singleton. Сам додаток допустимо зконфігурувати вже розширеним класом. Звісно, можна буде конкретизувати додаток певним екземпляром класу, потрібним в даний момент для виконання;

- допускає уточнення операцій та подання. Від класу Singleton можна породжувати підкласи, а додаток легко налаштувати примірником розширеного класу. Можна конкретизувати додаток примірником того класу, який необхідний під час виконання;

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

До мінусів даного паттерну проектування варто віднести лише те, що глобальні об’єкти, як такі, можуть бути шкідливі для програми, оскільки перешкоджають її масштабованості.

Паттерн Будівельник (Builder)

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

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

Мотивація застосування. Паттерн Будівельник, використовується коли:

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

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

Проблемна предметна область. Необхідно створити систему планування екскурсій по курортному місту. Гості курорту можуть вибрати готель, замовити квитки на атракціони, зарезервувати місця в ресторані і навіть замовити спеціальні заходи. Запланована відпустка виглядає приблизно так (рис. 4.4) [10]. Поїздки можуть розрізнятися по кількості днів і складовим розважальної програми. Наприклад, місцевий житель не має потреби в готелі, але хоче замовити обід і спеціальні заходи. Інший гість прилітає на курорт літаком, і йому необхідно забронювати номер у готелі, столик у ресторані квитки на заходи. Таким чином, нам потрібна гнучка структура даних, що може представляти програму відвідування з усіма можливими варіаціями; крім того, побудова курортної програми може складатися з декількох кроків.

Рис. 4.4. Схема складеного об’єкта

Як надати спосіб побудови складної структури даних, не змішуючи його з окремими етапами її створення? Необхідно створення курортної програми інкапсулювати в об’єкті (назвемо його «будівельником»), а клієнт використовує цей об’єкт для конструювання структури даних (рис. 4.5).

Рис. 4.5. Предметна область в термінах паттерна Будівельник

Або розглянемо іншу предметну область. Уявимо собі, що є конвеєр для випуску автомобілів. Робота конвеєра полягає в покроковій побудові складного продукту, яким у даному випадку є автомобіль. Конвеєр визначає загальну послідовність кроків (тобто алгоритм) конструювання. При цьому специфіка кожного з кроків визначається, головним чином, моделлю автомобіля, що збирається. Такий поділ загального алгоритму побудови і специфіки кожного з кроків дозволять компанії значно заощадити – на тому самому конвеєрі можуть випускатися автомобілі різних моделей з різними характеристиками.

З загальної технологічної точки зору, автомобіль на конвеєрі проходить такі етапи:

- зборка кузова;

- установка двигуна;

- установка коліс;

- фарбування;

- підготовка салону.

Технічні деталі процесів, що відбуваються на кожнім кроці, відомі вже конкретній технології виробництва моделі автомобіля. Нехай завод може робити автомобілі наступних моделей: автомобілі класу «Міні», спортивні автомобілі та позашляховики. При такій постановці виробничого процесу для компанії не складе проблем доповнити спектр моделей, що випускаються, новими зразками без змін загального конвеєрного циклу. Перенесемося тепер у світ ООП. Визначимо клас «Конвеєр», що буде прототипом реального конвеєра, тобто буде визначати загальну послідовність кроків конструювання. Метод «Зібрати» цього класу буде виконувати процес конструювання за допомогою виконання цих кроків без залежності від технічних деталей реалізації кожного кроку.

Відповідальність за реалізацію кроків конструювання покладемо на абстрактний клас, який назвемо «Технологія моделі». В результаті застосування конкретних підкласів класу «ТехнологіяМоделі» одержимо на виході різні моделі автомобілів, тобто екземпляри різних класів автомобілів. Визначимо такі підкласи класу «Технологія моделі»: «ТехнологіяМініАвто», «ТехнологіяСпортивнеавто», «ТехнологіяПозашляховеАвто». Кожна з цих технологій передбачає випуск таких моделей автомобілів: «Міні авто», «Спортивне авто», «ПозашляховеАвто».

Для початку виробництва автомобіля необхідно задати конкретну технологію для конвеєра і викликати метод «Зібрати». Після завершення процесу зборки готовий автомобіль можна одержати в об’єкті технології за допомогою методу «ОтриматиРезультат()».

Діаграма класів описаної об’єктно-орієнтованої моделі представлена на рисунку 4.6.

Побудовані моделі володіють рядом переваг:

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

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

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

Рис. 4.6. Діаграма класів моделі конвеєра по виробництву автомобілів

У загальному випадку структура паттерна Buіlder має вигляд, представлений на рисунку 4.7.

Учасники партерна.

1. Builder – це, власне, і є Будівельник, який представляє собою абстрактний інтерфейс для покрокового створення об’єкта Product по частинах.

2. ConcreteBuilder – конкретний Будівельник:

- реалізує кроки побудови складного об’єкта, визначені в базовому класі Buіlder;

- створює результат побудови (Product) і стежить за покроковим конструюванням;

- визначає інтерфейс для доступу до результату конструювання.

3. Director – розпорядник. Клас, що займається конструюванням об’єкта, використовуючи інтерфейс, представлений Будівельником:

- визначає загальний алгоритм конструювання, використовуючи для реалізації окремих кроків можливості класу Buіlder.

4. Product – підсумковий продукт, який отримується в результаті конструювання. Представляє собою складний конструйований об’єкт. ConcreteBuilder будує внутрішнє представлення продукту і визначає процес його складання:

- містить класи, які визначають складові частини, у тому числі інтерфейси для складання кінцевого результату з частин.

Рис. 4.7. Діаграма класів паттерна Будівельник

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

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