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

Question

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

Он говорит:

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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