@gavenkoa другой вопрос касается только прокси и декоратора
user310291
2
Невероятно, так как некоторые закрытые вопросы показывают себя настолько полезными.
Люк
Ответы:
286
Адаптер адаптирует данный класс / объект к новому интерфейсу. В первом случае обычно используется множественное наследование. В последнем случае объект оборачивается соответствующим объектом адаптера и передается вокруг. Здесь мы решаем проблему несовместимых интерфейсов .
Фасад больше похож на простой вход в сложный набор функций. Вы создаете черный ящик, чтобы ваши клиенты меньше беспокоились, т.е. упрощали интерфейсы .
Прокси предоставляет тот же интерфейс, что и класс прокси-сервера, и, как правило, выполняет некоторые вспомогательные функции самостоятельно. (Таким образом, вместо того, чтобы делать несколько копий тяжелого объекта, Xвы делаете копии легкого прокси-сервера, Pкоторый, в свою очередь, управляет Xвашими вызовами и переводит их по мере необходимости.) Вы решаете проблему клиента от необходимости управлять тяжелым и / или сложным объектом .
Декоратор используется, чтобы добавить больше пороха к вашим объектам (обратите внимание на термин объекты - вы обычно украшаете объекты динамически во время выполнения). Вы не скрываете / не ухудшаете существующие интерфейсы объекта, а просто расширяете его во время выполнения .
Теперь, когда у вас есть декоратор, вы, вероятно, захотите узнать, почему акцент на объекте слова - некоторые языки (например, Java) просто не допускают виртуальное наследование (то есть множественное наследование, как в C ++), чтобы вы могли выполнить это в время компиляции.
Поскольку мы перетаскивали несколько наследований (и страшный ромб), вы будете искать миксины - упорядоченные линейные цепочки интерфейсов, чтобы обойти проблемы множественного наследования. Тем не менее, миксины не так хорошо смешиваются. И в итоге мы получаем черты - да, те маленькие капли поведения без состояния, которые вы все время видите в параметрах шаблона в C ++. Черты стараются изящно решать вопросы композиции и декомпозиции поведения, не прибегая ни к множественному наследованию, ни к упорядоченному сцеплению.
НТН! Я пытался положить столько, сколько я могу, не будучи слишком расплывчатым. Извините за неспособность сделать лучше. Я прочитал (кандидатская диссертация) статьи только по чертам. Поэтому мои знания довольно ограничены, и я не достаточно хорош, чтобы вписаться во все модели в этом пространстве;)
опаской
Вы ожидали в будущем вопрос о миксинах и чертах, но я еще не видел их!
user310291
1
Хорошая ссылка для сравнения (через википедию) для первых трех (Декоратор совсем другой): NetObjectives
Liviu
@Liviu Ваша ссылка мертва. Я предполагаю, что вы изначально указывали там , но контент теперь, кажется, за логином.
Джонатан Х
@Sheljohn Ссылка обновлена: p: Хорошая ссылка для сравнения (через википедию) для первых трех (Декоратор совсем другой) NetObjectives (Получение текста, см. «Betweem»: «Один из наиболее частых вопросов, которые я получаю в классе, это« что разница между Adapter, Proxy и Facade? Они действительно кажутся мне одинаковыми ».
Ливиу
16
Фасад
Например, вы можете использовать фасад для упрощения вызовов API. Взгляните на этот пример удаленного фасада. Идея заключается в том, что полная реализация кода на сервере скрыта от клиента. Клиент вызывает 1 метод API, который, в свою очередь, может сделать 1 или более вызовов API на сервере.
адаптер
Хороший пример этого можно найти здесь , в Википедии. Клиентский объект Sourceхотел бы вызвать метод для другого объекта Target, но интерфейс этого другого объекта отличается от того, что ожидает клиент.
Введите объект адаптера.
Он может принимать вызов от Sourceобъекта и за кулисами вызывать Targetметод, который следует использовать.
Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)
Что касается Прокси, у меня нет никакого опыта в этом шаблоне проектирования.
Ответы:
Адаптер адаптирует данный класс / объект к новому интерфейсу. В первом случае обычно используется множественное наследование. В последнем случае объект оборачивается соответствующим объектом адаптера и передается вокруг. Здесь мы решаем проблему несовместимых интерфейсов .
Фасад больше похож на простой вход в сложный набор функций. Вы создаете черный ящик, чтобы ваши клиенты меньше беспокоились, т.е. упрощали интерфейсы .
Прокси предоставляет тот же интерфейс, что и класс прокси-сервера, и, как правило, выполняет некоторые вспомогательные функции самостоятельно. (Таким образом, вместо того, чтобы делать несколько копий тяжелого объекта,
Xвы делаете копии легкого прокси-сервера,Pкоторый, в свою очередь, управляетXвашими вызовами и переводит их по мере необходимости.) Вы решаете проблему клиента от необходимости управлять тяжелым и / или сложным объектом .Декоратор используется, чтобы добавить больше пороха к вашим объектам (обратите внимание на термин объекты - вы обычно украшаете объекты динамически во время выполнения). Вы не скрываете / не ухудшаете существующие интерфейсы объекта, а просто расширяете его во время выполнения .
Теперь, когда у вас есть декоратор, вы, вероятно, захотите узнать, почему акцент на объекте слова - некоторые языки (например, Java) просто не допускают виртуальное наследование (то есть множественное наследование, как в C ++), чтобы вы могли выполнить это в время компиляции.
Поскольку мы перетаскивали несколько наследований (и страшный ромб), вы будете искать миксины - упорядоченные линейные цепочки интерфейсов, чтобы обойти проблемы множественного наследования. Тем не менее, миксины не так хорошо смешиваются. И в итоге мы получаем черты - да, те маленькие капли поведения без состояния, которые вы все время видите в параметрах шаблона в C ++. Черты стараются изящно решать вопросы композиции и декомпозиции поведения, не прибегая ни к множественному наследованию, ни к упорядоченному сцеплению.
источник
Фасад
Например, вы можете использовать фасад для упрощения вызовов API. Взгляните на этот пример удаленного фасада. Идея заключается в том, что полная реализация кода на сервере скрыта от клиента. Клиент вызывает 1 метод API, который, в свою очередь, может сделать 1 или более вызовов API на сервере.
адаптер
Хороший пример этого можно найти здесь , в Википедии. Клиентский объект
Sourceхотел бы вызвать метод для другого объектаTarget, но интерфейс этого другого объекта отличается от того, что ожидает клиент.Введите объект адаптера.
Он может принимать вызов от
Sourceобъекта и за кулисами вызыватьTargetметод, который следует использовать.Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)Что касается Прокси, у меня нет никакого опыта в этом шаблоне проектирования.
источник