Адаптер (шаблон проектування)

Адаптер, Adapter — структурний шаблон проектування, призначений для організації використання функцій об'єкта, недоступного для модифікації, через спеціально створений інтерфейс.

Призначення

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

Застосування

Адаптер передбачає створення класу-оболонки з необхідним інтерфейсом.

Структура

UML діаграма, що ілюструє структуру шаблону проектування Адаптер (з використанням множинного наслідування)

Учасники

Клас Adapter приводить інтерфейс класу Adaptee у відповідність з інтерфейсом класу Target (спадкоємцем якого є Adapter). Це дозволяє об'єктові Client використовувати об'єкт Adaptee так, немов він є екземпляром класу Target.

Наслідки

Шаблон Адаптер дозволяє включати вже існуючі об'єкти в нові об'єктні структури, незалежно від відмінностей в їхніх інтерфейсах.

Реалізація

Включення вже існуючого класу в інший клас. Інтерфейс включаючого класу приводиться у відповідність з новими вимогами, а виклики його методів перетворяться у виклики методів включеного класу.

 

Декоратор (шаблон проектування)

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

Основні характеристики

Завдання

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

Спосіб вирішення

Декоратор передбачає розширення функціональності об'єкта без визначення підкласів.

Учасники

Клас ConcreteComponent — клас, в який за допомогою шаблону Декоратор додається нова функціональність. В деяких випадках базова функціональність надається класами, похідними від класу ConcreteComponent. У подібних випадках клас ConcreteComponent є вже не конкретним, а абстрактним. Абстрактний клас Component визначає інтерфейс для використання всіх цих класів.

Наслідки

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

Реалізація

Створюється абстрактний клас, що представляє як початковий клас, так і нові функції, що додаються в клас. У класах-декораторах нові функції викликаються в необхідній послідовності — до або після виклику подальшого об'єкта.

Зауваження і коментарі

• Хоча об'єкт-декоратор може додавати свою функціональність до або після функціональності основного об'єкта, ланцюжок створюваних об'єктів завжди повинен закінчуватися об'єктом класу ConcreteComponent.
• Базові класи мови Java широко використовують шаблон Декоратор для організації обробки операцій введення-виведення.

 

4.3. Замісник (шаблон проектування)

Шаблон Proxy (Заступник ) — Шаблон проектування. Надає об'єкт, що контролює доступ, перехоплюючи всі виклики до нього.

Проблема

Необхідно управляти доступом до об'єкта, так щоб створювати громіздкі об'єкти «на вимогу».

Вирішення

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

«Заступник» може мати і інші обов'язки, а саме:

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

4.4.Компонувальник (Composite) /Матеріал відсутній/

4.5. Міст (шаблон проектування)

Міст (англ. Bridge) - шаблон проектування, відноситься до класу структурних шаблонів.

Призначення

Відокремити абстракцію від її реалізації таким чином, щоб перше та друге можна було змінювати незалежно одне від одного.

Мотивація

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

Застосовність

Слід використовувати шаблон Міст у випадках, коли:

• треба запобігти постійній прив'язці абстракції до реалізації. Так, наприклад, буває коли реалізацію необхідно обрати під час виконання програми;
• як абстракції, так і реалізації повинні розширюватись новими підкласами. У цьому разі шаблон Міст дозволяє комбінувати різні абстракції та реалізації та змінювати їх незалежно одне від одного;
• зміни у реалізації не повинні впливати на клієнтів, тобто клієнтський код не повинен перекомпілюватись;
• треба повністю сховати від клієнтів реалізацію абстракції;
• треба розподілити одну реалізацію поміж кількох об'єктів (можливо застосовуючи підрахунок посилань), і при цьому приховати це від клієнту.

Структура

UML діаграма, що описує структуру шаблону проектування Міст

• Abstraction – абстракція:
• визначає інтерфейс абстракції;
• зберігає посилання на об'єкт типу Implementor;
• RefinedAbstraction – уточнена абстракція:
• розширює інтерфейс, означений абстракцією Abstraction;
• Implementor – реалізатор:
• визначає інтерфейс для класів реалізації. Він не зобов'язаний точно відповідати інтерфейсу класу Abstraction. Насправді обидва інтерфейси можуть бути зовсім різними. Зазвичай, інтерфейс класу Implementor надає тільки примітивні операції, а клас Abstraction визначує операції більш високого рівня, що базуються на цих примітивах;
• ConcreteImplementor – конкретний реалізатор:
• містить конкретну реалізацію інтерфейсу класу Implementor.

Відносини

Об'єкт Abstraction містить у собі Implementor і перенаправляє йому запити клієнтa.