Яка різниця між фасадом та адаптером?

Я читав обидва визначення, і вони здаються абсолютно однаковими. Хтось міг би зазначити, у чому їх відмінності?

Дякую

На вікі-сторінці " Фасадний візерунок" про це є коротка примітка.

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

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

Шаблон адаптера просто пов'язує два несумісні інтерфейси.

EDIT: Швидка аналогія для моделі адаптера (на основі коментарів) може бути чимось на зразок адаптера DVI-VGA. Сучасні відеокарти часто є DVI, але у вас є старий монітор VGA. Завдяки адаптеру, який підключається до очікуваного DVI-входу вашої відеокарти та має власний вхід VGA, ви зможете налагодити роботу свого старого монітора з вашою новою відеокарткою.

Адаптер ==, завдяки чому квадратний кілочок помістився в круглий отвір

Фасад == одна панель управління для запуску всіх внутрішніх компонентів.

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

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

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

Фасад:

Ключові вивезення : (зі статті журналу Pande Kumar)

1. Візерунок фасаду більше схожий на помічник для клієнтських додатків
2. Шаблон фасаду можна застосувати в будь-якій точці розвитку, як правило, коли кількість інтерфейсів зростає і система стає складнішою .
3. Інтерфейси підсистеми не знають про Фасад, і вони не повинні мати жодної посилання на інтерфейс Фасад
4. Фасадну схему слід застосовувати для подібного типу інтерфейсів , її мета - створення єдиного інтерфейсу, а не декількох інтерфейсів, що виконує аналогічні завдання

Діаграма класу фасадів:

Адаптер:

1. Це структурна закономірність
2. Корисно працювати з двома несумісними інтерфейсами
3. Це змушує роботу працювати після їх розробки

Класова схема адаптера:

Більш детальну інформацію про адаптер ви можете знайти в цьому посту SE:

Різниця між схемою моста та схемою адаптера

Основні відмінності:

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

Подивіться також на статтю про створення джерела для кращого розуміння.

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

Мета a

фасад - простота

адаптер - це сумісність .

Фасад зазвичай контрастує з адаптером.

+--------------------------------------------------------------+-----------------------------------------------+
|                            Facade                            |                    Adapter                    |
+--------------------------------------------------------------+-----------------------------------------------+
| Simplifies multiple complex components with single interface | Provides differnet interface for an interface |
| Works with multiple components                               | Works with single component                   |
| Control panel is an example                                  | A power adapter is an example                 |
| High-level interface                                         | Low-level interface                           |
+--------------------------------------------------------------+-----------------------------------------------+

Як звичайно, існують подібності між декількома закономірностями. Але я побачив би це так:

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

Я спробую пояснити це простими словами, без особливої ​​формальності.

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

З іншого боку, адаптер можна використовувати для інтеграції інших зовнішніх компонентів, які можуть мати той самий функціонал, який вам потрібен, але їх функції не називаються зовсім однаково. Скажіть, у вас є Carклас у вашому домені, і ви працюєте з зовнішнім постачальником автомобілів, який також визначає клас автомобілів. У цьому класі у вас є функція, car.getDoors()але зовнішній постачальник має еквівалент car.getNumDoors(). Ви не хочете змінювати спосіб виклику цієї функції, тому ви можете використовувати клас адаптера, щоб обернути зовнішній клас автомобіля, щоб виклик getDoors()адаптера був делегований getNumDoors()зовнішньому класу.

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

Шаблон фасаду має відомий інтерфейс, який є низьким рівнем / дрібнозернистим, і обертає його інтерфейсом більш високого рівня / курсу. Має єдиний інтерфейс, який було спрощено обертанням іншого.

Адаптер змушує два інтерфейси працювати разом.

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

Фасад

Тези складності для надання більш простого інтерфейсу. Скажімо, наприклад, комп'ютерна ОС резюмує складність базового обладнання. Або мови програмування високого рівня (Python / JavaScript) резюмують складність у порівнянні з мовою низького рівня (C).

Перехідник

Це аналоги апаратних адаптерів. Скажіть, ви хочете підключити a USB deviceдо serial port, вам знадобиться USB-serial port adapter.

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

Шаблон фасаду спрощує складну підсистему (що має декілька компонентів) з одним інтерфейсом.

Різниця між цими двома шаблонами очевидна, але не в царині шаблонів дизайну, а доменного моделювання. Далі я поясню, чому.

По-перше, я хочу ще раз сказати, що інші сказали тут, а потім додам примітку:

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

З іншого боку, Адаптер - це обгортка навколо іншої послуги чи об'єкта. Це робить загорнутий об'єкт відповідним стандартному інтерфейсу, якого очікує клієнт. Скажімо, є на об’єкті "Леджер" метод, який потрібно здійснити налаштування (змінити його параметри, змінити назву тощо). Можна обернути його адаптером.

Тепер все ще різниця може бути не зрозумілою. Ось тут я хочу знайти ключову різницю між цими двома моделями, не залишаючи місця для подальшої плутанини :

Фасад не змінює модель домену іншої підсистеми, в той час як адаптер робить. Це ключова відмінність. Період.

Ось чому ви поєднуєте ці два, коли створюєте антикорупційний шар . Скажімо, у вас є підсистема, яку ви хочете використовувати, але ви не хочете, щоб її доменна модель заплутувала вашу модель домену. Що б ти зробив? Ви створили б антикорупційний шар. Як? Ви спочатку створюєте Фасад, який спрощує доступ до інтерфейсу для підсистеми, а потім адаптери для об’єктів домену, що використовуються в цьому інтерфейсі (пам’ятайте, фасад все ще містить модель домену для іншої підсистеми), щоб він відповідав вашій моделі.

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

Я читав обидва визначення, і вони здаються абсолютно однаковими.

Дійсно?

Я помітив, що термін « Адаптер» іноді використовується для опису того, що насправді є Stategy , можливо тому, що слово є більш виразним.

Наприклад, у Zend Framework всі класи Adapter насправді є реалізацією шаблону стратегії , оскільки вони лише загортають нативний код за класами, щоб мати декілька способів поведінки.

Адаптери часто використовуються для обгортання застарілого або "старого" коду.

Основна мета шаблону " Фасад" - полегшити використання класу або підсистеми, тоді як головна мета шаблону " Адаптер" - пристосувати інтерфейс до того, що очікує клієнт.