ЛК.12 – Базові шаблони проектування

Стійкий до змін.
Фасад.

Перелік питань

те, як з класів та об’єктів утворюються більші структури.
Структурні шаблони

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

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

1. Адаптер

для клієнтів) на окремий об’єкт, а не на клас в

цілому.
Рекомендації
Застосування кількох «Декоратор» до одного «Компоненту» дозволяє довільним чином поєднувати обов’язки, наприклад, одна властивість можна додати двічі.

2. Декоратор

породження підкласів (наслідування). «Компонент» визначає інтерфейс для об’єктів, на які

можуть бути динамічно покладені додаткові обов’язки, «КонкретнийКомпонент» визначає об’єкт, на який покладаються додаткові обов’язки, «Декоратор» – зберігає посилання на об’єкт «Компонент» і визначає інтерфейс, відповідний інтерфейсу «Компонента». «КонкретнийДекоратор» покладає додаткові обов’язки на компонент. «Декоратор» переадресує запити об’єкту «Компонент».

обов’язки під час виконання програми в той час як при

використанні наслідування треба було б створювати новий клас для кожного додаткового обов’язку. Даний патерн дозволяє уникнути перевантажених методами класів на верхніх рівнях ієрархії – нові обов’язки можна додавати в міру необхідності.
Недоліки
«Декоратор» і його «Компонент» не ідентичні, і, крім того, виходить що система складається з великої кількості дрібних об’єктів, які схожі один на одного і розрізняються тільки способом взаємозв’язку а не класом і не значеннями своїх внутрішніх змінних – така система складна в вивчення та налагодженні.

об’єкта, так щоб створювати громіздкі об’єкти «на вимогу».
Рішення
Створити сурогат громіздкого

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

3. Замісник

відповідати за кодування запиту та його аргументів і відправку закодованого

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

і т.п. необхідна інформація.
Рішення
Призначити обов’язок акумуляції інформації, розрахунку і т.п.

якомусь класу (інформаційному експерту), що володіє необхідною інформацією.
Рекомендації
Інформаційним експертом може бути не один клас, а декілька.

4. Інформаційний експерт

(продаж окремого виду товару в рамках продажу в цілому), «ТоварСпеціфікація»

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

одночасно?
Рішення
Визначити класи для композитних і атомарних об’єктів таким чином, щоб

вони реалізовували один і той же інтерфейс.
Приклад
Див паттерн «Стратегія», необхідно врахувати декілька знижок різних видів (залежать від часу, типу покупця, типом обраного продукту). Як застосовувати політику ціноутворення? Виробляється стратегія пріоритету знижок, об’єкт «Продаж» не повинен володіти інформацією про застосовувані знижки, але можна було б застосувати стратегію розрахунку знижок. Створюється новий клас «РозрахунокЗнижкиАлгоритмКомпозит».

5. Компонувальник

абстракцію від реалізації так, щоб і те і інше можна

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

6. Міст

«УточненнаАбстракція» розширює інтерфейс, визначений «абстракціє». «Реалізація» визначає інтерфейс для класів

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

час виконання. Крім того, слід згадати, що поділ класів «Абстракція»

і «Реалізація» усуває залежності від реалізації, що встановлюються на етапі компіляції: щоб змінити клас «Реалізація» зовсім не обов’язково перекомпілювати клас «Абстракція».

екземпляра класу і зв’язуванні його з іншим класом.
Рішення
Розподілити обов’язки між

об’єктами так, щоб ступінь пов’язаності залишалася низькою.

7. Низька зв’язаність

«Платіж» виконується об’єктом «Реєстрація» (ведеться рестир). Нижче наводяться 2 способи

створення екземпляра класу «Платіж». Верхній малюнок – з використанням патерну «Творець», нижній – з використанням «Низька зв’язаність». Останній спосіб забезпечує більш низький ступінь зв’язування.

суті, число яких дуже велика для подання об’єктами. Має сенс

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

8. Пристосуванець

в кожному контексті він виглядає як незалежний об’єкт (відрізняється від

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

щоб зміна одних її елементів не впливало на інші?
Рішення
Ідентифікувати точки

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

9. Стійкий до змін

реалізацій або інтерфейсів, наприклад, з підсистемою, якщо небажано високе зв’язування

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

10. Фасад