В чем разница между шаблоном фасада и адаптера?

Я читал оба определения, и они кажутся совершенно одинаковыми. Может ли кто-нибудь указать, в чем их различия?

Спасибо

На вики-странице Facade Pattern есть краткое примечание об этом.

«Адаптер используется, когда оболочка должна уважать конкретный интерфейс и поддерживать полиморфное поведение. С другой стороны, фасад используется, когда требуется более простой или более простой интерфейс для работы».

Я слышал аналогию, что вы должны подумать о своем универсальном пульте дистанционного управления, который вы настроили для работы со всеми вашими стереосистемами - вы нажимаете «вкл», и он включает вашу кабельную приставку, ресивер и телевизор. Может быть, это действительно модный домашний кинотеатр, и он приглушает свет и затемняет шторы. Это фасад - одна кнопка / функция, которая выполняет более сложный набор шагов.

Шаблон адаптера просто связывает два несовместимых интерфейса.

РЕДАКТИРОВАТЬ: Краткая аналогия для шаблона адаптера (на основе комментариев) может быть чем-то вроде адаптера DVI-to-VGA. Современные видеокарты часто имеют DVI, но у вас старый монитор VGA. С адаптером, который подключается к ожидаемому входу DVI вашей видеокарты и имеет собственный вход VGA, вы сможете заставить свой старый монитор работать с вашей новой видеокартой.

Адаптер == вставка квадратного штифта в круглое отверстие.

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

Честно говоря, многие шаблоны можно реализовать одинаково программно - разница только в намерениях.

Шаблон проектирования адаптера предназначен для «перевода» интерфейса одного или нескольких классов в интерфейс, который клиент ожидает использовать - адаптер переводит вызовы ожидаемого интерфейса в реальный интерфейс, который используют обернутые классы.

Паттерн Фасад используется, когда требуется более простой интерфейс (и, опять же, его можно реализовать таким же образом, обернув нарушающие классы). Нельзя сказать, что вы используете фасад, когда существующий интерфейс несовместим, как раз тогда, когда вам нужно чтобы сделать его более читабельным, менее плохо спроектированным и т. д.

Фасад:

Ключевые выводы: (из статьи Панкаджа Кумара в journaldev )

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

Схема классов фасада:

Адаптер:

1. Это структурный образец
2. Полезно работать с двумя несовместимыми интерфейсами
3. Это заставляет вещи работать после того, как они созданы

Диаграмма классов адаптера:

Вы можете найти более подробную информацию об адаптере в этом сообщении SE:

Разница между шаблоном моста и шаблоном адаптера

Ключевые отличия:

1. Фасад определяет новый интерфейс, тогда как Адаптер использует старый интерфейс . Адаптер заставляет два существующих интерфейса работать вместе, а не определять совершенно новый
2. Адаптер и Фасад являются оболочками; но это разные обертки. Целью Facade является создание более простого интерфейса, а намерение адаптера - разработать дизайн для существующего интерфейса.

Взгляните также на исходную статью для лучшего понимания.

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

Цель

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

Адаптер является совместимость .

Фасад обычно противопоставляется Адаптеру.

+--------------------------------------------------------------+-----------------------------------------------+
|                            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(). Вы не хотите изменять способ вызова этой функции, поэтому вы можете использовать класс адаптера для обертывания внешнего класса Car, чтобы вызов getDoors()адаптера был делегирован getNumDoors()внешнему классу.

Шаблон адаптера позволяет двум, ранее несовместимым, интерфейсам работать друг с другом. Имеет 2 отдельных интерфейса.

Паттерн Фасад берет известный интерфейс, который является низкоуровневым / мелкозернистым, и объединяет его с более высокоуровневым / детализированным интерфейсом. Имеет единый интерфейс, который был упрощен за счет объединения с другим.

Адаптер позволяет двум интерфейсам работать вместе.

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

Фасад

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

Адаптер

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

Шаблон адаптера связывает два несовместимых интерфейса, предоставляя новый интерфейс.

Шаблон фасада упрощает сложную подсистему (состоящую из нескольких компонентов) с помощью единого интерфейса.

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

Во-первых, я хочу повторить, что здесь говорили другие, а затем я добавлю примечание:

Фасад - это интерфейс к подсистеме (внешней или устаревшей системе), который упрощает доступ для клиента (нас). Фасад скрывает интерфейс другой подсистемы (объединяет некоторые вызовы или скрывает некоторые API, которые нам не нужны), поэтому ваш клиент получает доступ к этой подсистеме только через этот фасад.

С другой стороны, адаптер - это оболочка для другой службы или объекта. Это заставляет обернутый объект соответствовать стандартному интерфейсу, которого ожидает клиент. Допустим, у объекта «Ledger» есть метод, который вам нужно настроить (изменить его параметры, изменить его имя и т. Д.). Можно обернуть переходником.

И все же разница может быть неясной. Вот где я хочу выделить ключевое различие между этими двумя шаблонами, не оставляя места для дальнейшей путаницы :

Фасад не изменяет модель предметной области другой подсистемы, в отличие от адаптера. Это ключевое отличие. Период.

Вот почему вы комбинируете эти два при создании антикоррупционного слоя . Допустим, у вас есть подсистема, которую вы хотите использовать, но вы не хотите, чтобы ее модель предметной области мешала вашей модели предметной области. Что бы вы сделали? Вы бы создали слой защиты от коррупции. Как? Сначала вы создаете фасад, который упрощает доступ к интерфейсу для подсистемы, а затем адаптеры для объектов домена, используемых в этом интерфейсе (помните, что фасад по-прежнему содержит модель домена для другой подсистемы), поэтому он соответствует вашей модели.

Многие шаблоны проектирования можно использовать в моделировании предметной области. Это также верно для шаблонов проектирования фасадов и адаптеров. Хотя разница между этими двумя шаблонами может быть нечеткой в ​​области «шаблонов проектирования», она более очевидна в области «моделирования предметной области».

Я читал оба определения, и они кажутся совершенно одинаковыми.

В самом деле ?

Я заметил, что термин адаптер иногда используется для описания того, что на самом деле является Stategy , возможно, потому, что это слово более выразительно.

Например, в Zend Framework все классы адаптера на самом деле являются реализациями шаблона стратегии , потому что они только оборачивают собственный код за классами, чтобы иметь несколько вариантов поведения.

Адаптеры часто используются для обертывания устаревшего кода или кода «старого стиля».

Основная цель шаблона Facade - упростить использование класса или подсистемы, в то время как основная цель шаблона адаптера - настроить интерфейс в соответствии с ожиданиями клиента.