Можете ли вы дать какое-нибудь хорошее объяснение, в чем разница между Proxy и Decorator ?
Основное различие, которое я вижу, заключается в том, что когда мы предполагаем, что Proxy использует композицию, а Decorator использует агрегацию, тогда кажется очевидным, что, используя несколько (один или несколько) декораторов, вы можете изменять / добавлять функции к уже существующему экземпляру (украшать), тогда как Прокси- сервер имеет собственный внутренний экземпляр прокси-класса и делегирует ему некоторые дополнительные функции (поведение прокси).
Вопрос в том, остается ли прокси, созданный с помощью агрегации, прокси или, скорее, декоратором ? Разрешено ли (по определению в шаблонах GoF) создавать прокси с агрегацией?
oop
design-patterns
decorator
proxy-pattern
Лукаш Жешотарски
источник
источник
Ответы:
Вот прямая цитата из GoF (стр. 216).
Популярные ответы показывают, что Прокси-сервер знает конкретный тип своего делегата. Из этой цитаты видно, что это не всегда так.
Разница между Proxy и Decorator согласно GoF в том, что Proxy ограничивает клиента. Декоратора нет. Proxy может ограничить то , что клиент делает , контролируя доступ к функциональным возможностям ; или он может ограничить то, что клиент знает , выполняя действия, которые невидимы и неизвестны клиенту. Decorator делает обратное: он улучшает то, что делает его делегат, так, чтобы это было видно клиентам.
Можно сказать, что Proxy - это черный ящик, а Decorator - это белый ящик.
Отношения композиции между оболочкой и делегатом - это неправильное отношение, на котором следует сосредоточиться при противопоставлении прокси и декоратора, поскольку композиция - это общая черта этих двух шаблонов. Отношения между оболочкой и клиентом - вот что отличает эти два шаблона.
источник
Настоящая разница не в праве собственности (состав против агрегирования), а скорее в информации о типе.
Декоратор будет всегда прошел delegatee. Proxy может создать его сам, или он может иметь его вводили.
Но Прокси-сервер всегда знает (более) конкретный тип делегата. Другими словами, Прокси-сервер и его делегат будут иметь один и тот же базовый тип, но Прокси указывает на некоторый производный тип. Decorator указывает на его собственный базовый тип. Таким образом, разница заключается в информации о типе делегата во время компиляции.
На динамическом языке, если делегат внедрен и имеет тот же интерфейс, то разницы нет.
Ответ на ваш вопрос - «Да».
источник
Шаблон декоратора фокусируется на динамическом добавлении функций к объекту, тогда как шаблон прокси ориентирован на управление доступом к объекту.
РЕДАКТИРОВАТЬ:-
Связь между прокси и реальным объектом обычно устанавливается во время компиляции, прокси каким-то образом создает его экземпляр, тогда как декоратор назначается субъекту во время выполнения, зная только интерфейс субъекта.
источник
Декоратор получает ссылку на декорированный объект (обычно через конструктор), в то время как Прокси отвечает за это сам.
Прокси-сервер может вообще не создавать экземпляр объекта-оболочки (например, ORM для предотвращения ненужного доступа к БД, если поля / геттеры объекта не используются), в то время как Decorator всегда содержит ссылку на фактический завернутый экземпляр.
Прокси-сервер обычно используется фреймворками для добавления безопасности или кеширования / бездействия и создается фреймворком (а не самим обычным разработчиком).
Декоратор обычно используется для добавления нового поведения к старым или устаревшим классам самим разработчиком на основе интерфейса, а не фактического класса (поэтому он работает с широким спектром экземпляров интерфейса, прокси - это конкретный класс).
источник
Ключевые отличия:
В исходной статье отлично цитируются сходства и различия.
Связанные вопросы / ссылки по SE:
Когда использовать шаблон декоратора?
В чем точная разница между шаблонами адаптера и прокси?
источник
Прокси-сервер и декоратор различаются по назначению и сосредоточению внимания на внутренней реализации. Прокси-сервер предназначен для использования удаленного, перекрестного процесса или межсетевого объекта, как если бы он был локальным объектом. Декоратор предназначен для добавления нового поведения к исходному интерфейсу.
Хотя оба шаблона похожи по структуре, основная сложность прокси заключается в обеспечении надлежащей связи с исходным объектом. Decorator, с другой стороны, фокусируется на реализации добавленного поведения.
источник
Потребовалось время, чтобы понять этот ответ и то, что он на самом деле означает. Несколько примеров должны прояснить ситуацию.
Proxy
первый:И :
И у этого есть вызывающий
Authorization
, довольно тупой:Пока что ничего необычного, правда? Получите токен от определенной службы, используйте этот токен. Теперь появляется еще одно требование к изображению, добавление регистрации: это означает, что каждый раз регистрирует токен. В этом случае все просто, просто создайте
Proxy
:Как нам это использовать?
Обратите внимание, что
LoggingDBAuthorization
содержит экземплярDBAuthorization
. КакLoggingDBAuthorization
иDBAuthorization
реализоватьAuthorization
.DBAuthorization
) базового интерфейса (Authorization
). Другими словами, Прокси-сервер точно знает , что проксируется.Decorator
:Все начинается примерно так же, как
Proxy
и с интерфейсом:и его реализация:
А теперь мы хотим добавить более опытного кандидата, который добавляет свой балл на собеседовании и баллы другого
JobSeeker
:Обратите внимание, как я сказал это плюс одно от другого ищущего работу , а не
Newbie
. ADecorator
не знает точно, что он украшает, он знает только контракт этого украшенного экземпляра (он знаетJobSeeker
). Обратите внимание, что это не похоже наProxy
; который, напротив, точно знает, что украшает.Вы можете спросить, есть ли на самом деле разница между двумя шаблонами проектирования в этом случае? Что, если бы мы попытались записать
Decorator
какProxy
?Это определенно вариант, который подчеркивает, насколько близки эти модели; они по-прежнему предназначены для разных сценариев, как описано в других ответах.
источник
Прокси предоставляет тот же интерфейс для обернутого объекта, Decorator предоставляет ему расширенный интерфейс, а Proxy обычно самостоятельно управляет жизненным циклом своего объекта службы, тогда как состав декораторов всегда контролируется клиентом.
источник