В чем разница между CoR и Decorator? Почему CoR - это поведенческий образец? Почему декоратор - это структурный паттерн?

Этот ответ почти описывает первую половину вопроса.

Он говорит:

Прочитав определения «Банды четырех», я не уверен, что есть реальная разница. (включены для удобства)

  • Декоратор: позволяет динамически обертывать объекты, чтобы изменить их существующие обязанности и поведение.
  • Цепочка ответственности: дает возможность нескольким объектам обрабатывать запрос путем связывания получающих объектов вместе.

Википедия немного уточняет их, но некоторые из них произвольны.

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

  • Ссылки цепочки ответственности обрабатывают данные только в том случае, если это их ответственность; но определение ответственности и обработка данных являются частью поведения. Декораторы могут сделать это так же легко.

  • Декоратор требует, чтобы вы позвонили делегату.

  • Ссылка на чистую CoR должна вызывать делегата только в том случае, если он не обрабатывает данные. Первые два атрибута на самом деле не различают шаблоны.

Вторые два работают, но способ, которым обычно реализуются Decorator и CoR, не применяет эти атрибуты - разработчик просто надеется, что никто не напишет Decorator, который разрывает цепочку, или CoRLink, который продолжает цепочку после обработки данных.

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

Кроме того, почему они находятся в разных категориях? Кроме того, читая другие ответы здесь, похоже, что хотя структура почти такая же, цель другая. CoR предназначен для наличия пары потенциальных объектов, которые могут обрабатывать запрос, а объект, который будет обрабатывать запрос, заранее неизвестен. В то время как декоратор предназначен для обертывания объекта и добавления некоторых функций во время выполнения (почему я не могу сделать это с помощью CoR?). Есть ли смысл в том, что CoR (который предназначен для структурирования нескольких объектов, способных обрабатывать запрос вместе в цепочке) должен быть behavioral? Не кажется ли, что это должно быть structural? Кроме того, действительно ли это имеет смысл для Decorator (который предназначен для инкапсуляции некоторого поведения и присоединения его к какому-либо заданному объекту позже) как structural? Не кажется ли, что это должно быть behavioral?


oop design-patterns decorator chain-of-responsibility
person StackExchange123    schedule 08.05.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, что ответы в связанной (канонической) ветке в основном хороши, и их комбинация дает довольно полную картину этих двух шаблонов проектирования; но, возможно, было бы полезно добавить немного больше из книги вместе с немного другой терминологией.

Одна из упомянутых концепций заключается в том, что декораторы являются аддитивными. Каждый декоратор обрабатывает каждое сообщение. Это подразумевает количество элементов два или больше. Существует базовое поведение, которое клиент желает улучшить с помощью одного или нескольких дополнительных вариантов поведения, то есть минимум два поведения.

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

Однако самая большая разница заключается в том, где создается экземпляр составляющего объекта. Обычно экземпляры декораторов создаются непосредственно клиентом, потому что клиент точно знает, какие улучшения он хочет обернуть вокруг некоторого базового поведения. Когда клиент делает запрос, он явно знает получателей, потому что он объединил их вместе перед отправкой запроса.

Цепочка ответственности невидима для клиентов.

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

Это приводит к основной причине, по которой клиент будет вызывать CoR, а не декоратор: потому что у клиента недостаточно информации для выбора декоратора. CoR настраивается где-то еще, и клиент не знает, какие альтернативные обработчики доступны, или даже о том, что вызываемый им обработчик вообще является частью цепочки.

Декораторы выигрывают от более умного клиента. Цепочка ответственности - это продукт конфигурации.

Еще одна веская причина для реализации CoR - это когда ваше приложение уже спроектировано как некоторая форма иерархии или древовидной структуры. В случае, когда между объектами уже есть «преемники», добавить часть «Ответственность» относительно просто, потому что цепочка уже существует. GoF не раз отмечает, как CoR хорошо работает с Composite Pattern, потому что последний предоставляет ссылки для CoR для совмещения.

Я считаю, что это также может быть причиной классификации CoR как поведенческой модели. В случае, когда дерево объектов уже существует (что довольно часто), структурные изменения не требуются для реализации CoR. Это просто изменение поведения уже существующей структуры. С другой стороны, новый декоратор всегда вводит новое отношение композиции, которое представляет собой структурное изменение в соответствии с категориями GoF.

person jaco0646    schedule 09.05.2020