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

Ответ 1

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

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

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

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

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

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

Ответ 2

Фасад

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

Адаптер

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

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

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

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

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