Различия между шаблонами дизайна фасада, прокси, адаптера и декоратора?

Question

В чем разница между шаблонами дизайна Facade, Proxy, Adapter и Decorator?

Я никогда не читал четкого объяснения, что твой?

Answer 1

Адаптер адаптирует данный класс/объект к новому интерфейсу. В случае первого используется типичное наследование. В последнем случае объект обертывается соответствующим адаптивным объектом и проходит вокруг него. Проблема, которую мы здесь решаем, заключается в том, что несовместимых интерфейсов.

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

Прокси обеспечивает тот же интерфейс, что и класс прокси-класса, и, как правило, делает некоторые вещи для домашнего хозяйства самостоятельно. (Таким образом, вместо создания нескольких копий тяжелого объекта X вы делаете копии облегченного прокси P, который, в свою очередь, управляет X и переводит ваши вызовы по мере необходимости.) Вы решаете проблему с клиентом от управления тяжелым и/или сложный объект.

Декоратор используется для добавления дополнительного количества пороха в ваши объекты (обратите внимание на термин «объекты» - вы обычно динамически декорируете объекты во время выполнения). Вы не скрываете/не нарушаете существующие интерфейсы объекта, но просто расширяете его во время выполнения.

Теперь, когда у вас есть декоратор, вы, вероятно, захотите узнать, почему акцент на объекте слова - некоторые языки (например, Java) просто не позволяют виртуальное наследование (то есть множественное наследование как C++), чтобы вы могли выполнить это во время компиляции.

Поскольку мы тащили в нескольких наследствах (и страшный алмаз), вы будете смотреть на Mixins - которые упорядоченных линейные цепное интерфейсов, чтобы обойти проблемы множественного наследования. Тем не менее, mixins не смешивают это хорошо. И мы получаем черты - да те stateless маленькие капли поведения, которые вы видите всплывающие все время в параметрах шаблона на C++. Черты пытаются элегантно подойти к вопросам составления и декомпозиции поведения, не останавливаясь ни на нескольких наследованиях, ни на упорядоченной цепочке.

Answer 2

Фасад

Вы можете использовать фасад, например, для звонков на API проще. Посмотрите на this пример удаленного фасада. Идея здесь в том, что полная реализация кода на сервере скрыта от клиента. Клиент вызывает 1 метод API, который, в свою очередь, может сделать 1 или более вызовов API на сервере.

адаптер

Хорошим примером этого может быть найден here, в Википедии.Клиентский объект Source хотел бы вызвать метод на другом объекте Target, но интерфейс другого объекта отличается от того, что ожидает клиент.

Введите объект адаптера.

Можно позвонить по объекту Source и, за кулисами, вызвать метод Target, который следует использовать.

Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)

Что касается прокси, у меня нет никакого опыта этого шаблона.