Если In Proxy Pattern имеет интерфейс вместо фактического конкретного объекта Subject в классе Proxy, он эквивалентен шаблону Decorator

Шаблон прокси-сервера делегирует запрос реальному субъекту после выполнения некоторой дополнительной обработки, например, при применении проверок, если запрос должен быть обработан или не основан на нем, могут быть некоторые проверки учетных данных.

Он имеет диаграмму классов, как показано ниже

введите описание изображения здесь

Класс прокси имеет прямую ссылку на конкретный предмет.

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

введите описание изображения здесь

Наличие конкретного объекта в классе Proxy затрудняет модульное тестирование, поскольку классы должны зависеть только от интерфейсов, а не от реализаций. Мой вопрос: если шаблон прокси-сервера также имеет ссылку на интерфейс, открытый реальным субъектом, то он будет эквивалентен шаблону Decorator. В этом случае диаграмма классов прокси-шаблона также станет ниже

введите описание изображения здесь

Ответ 1

Это все о намерении. Функционально они будут эквивалентны, но точкой декоратора является динамическое добавление объектов в объект, тогда как прокси-сервер просто контролирует доступ к целевому объекту без добавления каких-либо дополнительных функций.

Таким образом, клиент прокси-сервера ожидает такой же результат, как если бы он работал с реальным объектом, в то время как клиент декоратора оставляет его декоратору для выполнения любой дополнительной логики до и/или после делегирования вызова целевой.

Итак, концептуально кажется, что в вашем примере вы все еще имеете дело с прокси-сервером.

Ответ 2

Да. Если вы посмотрите на структуру, она будет одинаковой для Декоратора и Прокси. Только намерение отличается.

Decorator:

  • Добавить поведение объекта во время выполнения. Наследование - это ключ к достижению этой функциональности, что является одновременно преимуществом и недостатком этого шаблона.
  • Изменяет поведение интерфейса.

например. (с цепочкой): java.io классы пакетов, связанные с интерфейсами InputStream и OutputStream

FileOutputStream fos1 = new FileOutputStream("data1.txt");  
ObjectOutputStream out1 = new ObjectOutputStream(fos1);

Последствия

  • Декорация более удобна для добавления функций в объекты вместо целых классов во время выполнения. С отделкой также можно динамически удалять добавленные функциональные возможности.
  • Декорация добавляет функциональность объектам во время выполнения, что затрудняет работу системы отладки.

Прокси-сервер:

  • Используйте его для ленивой инициализации, повышения производительности путем кэширования объекта и контроля доступа к клиенту/вызывающему. Он может обеспечить альтернативное поведение или вызвать реальный объект. Во время этого процесса он может создавать новый объект.
  • В отличие от Decorator, который позволяет связывать объекты, Proxy не позволяет цепочки.

например: java.rmi классы пакетов

Ключевые вынос:

  • Прокси обеспечивает тот же интерфейс. Декоратор обеспечивает расширенный интерфейс.
  • Decorator и Proxy имеют разные цели, но аналогичные структуры. Оба описывают, как обеспечить уровень косвенности другому объекту, а реализации содержат ссылку на объект, к которому они направляют запросы.

Полезные ссылки:

Decorator_pattern от wikiepdia

decorator от sourcemaking

decorator-pattern из oodesign

Proxy_pattern из wikipedia

proxy от sourcemaking

proxy-pattern из oodesign