Разница между моделями дизайна фасада, Прокси, адаптера и декоратора? [закрытый]


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

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

2 113

2 ответа:

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

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

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

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

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

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

фасад

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

адаптер

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

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

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

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

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