Адаптер

Типова ситуація для застосування.

Є розроблений іншими авторами клас (назвемо його CForeign);

він підтримує функціональність, що в точності відповідає нашим потребам;

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

Іншими словами, нашій програмі потрібен клас, що вирішує певні задачі, і клас CForeign їх вирішує;

нашій програмі потрібно, щоби методи при цьому мали певні фіксовані назви, що відповідають нашому інтерфейсу INative, а у класу CForeign методи мають інші назви.

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

Шаблон «Адаптер» призначений для подолання цієї перешкоди.

Ідея шаблону

Оголосити власний клас (назвемо його CForeignToNativeAdapter)

має інтерфейс INative,

містить член-об’єкт (покажчик або посиланя на об’єкт) класу CForeign,

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

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

Шаблон «Адаптер» схожий за принципами реалізації на шаблон «Міст»: в обох об’єкт-оболонка невидимим для клієнта чином делегує (переадресовує) виклики методів до іншого об’єкта, який робить всю справжню роботу.

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

Шаблон «Фасад» також має спільну рису з шаблоном «Адаптер»:

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

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

Фасад

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

Уявімо деяку відносно обособлену підсистему програмної системи.

Підсистема має складну внутрішню будову: містить багато об’єктів та складні зв’язки між ними.

Виконання задач підсистеми реалізовано через непрості операції над багатьма об’єктами.

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

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

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

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

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

В прикладі з медіатекою фасад має невеликий перелік операцій (додати, видалити композицію, вибрати композицію для прослуховування), клієнт безпосередньо звертається лише до них.

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

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

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

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