CoR和decorator有什么区别？为什么CoR是一种行为模式？为什么Decorator是一种结构模式？

Question

这个答案几乎描述了问题的前半部分。

上面写着：

看过“四人帮”的定义后，我不相信这有什么真正的区别。（为方便起见包括在内）

• 装饰器：允许对对象进行动态包装，以便修改它们现有的职责和行为
• 责任链：通过将接收对象链接在一起，使多个对象有机会处理请求

维基百科对它们做了一些补充，但有些是武断的。

>

装饰器通常作为链表实现。但我认为这太低了，不能被认为是模式的“一部分”。

责任链只处理数据，如果这是他们的责任；但确定责任和数据处理都是行为的一部分。装修师也可以很容易地做到这一点。

Decorator要求您调用委托。

一个“纯”CoR链接应该只在委托不处理数据的情况下调用它。前两个属性并不能真正区分模式。

后两个是，但Decorator和CoR的实现方式并不强制这些属性--设计者只是希望没有人在处理数据后编写破坏链的Decorator或延续链的CoRLink。

两种模式的结构几乎完全相同。是什么迫使decorator模式以这种方式实现的？没有ConcreteElement和一些Decorator，是什么阻止我只让每个Decorator指向它包装的对象，并且当包装对象的指针为NULL时，执行与ConcreteElement相同的操作？是什么使每一个结构特定于它的模式？

还有，为什么是分门别类的呢？此外，阅读这里的其他答案，看起来即使结构几乎相同，但意图不同。cor用于具有几个可能处理请求的潜在对象，而将处理请求的对象是事先不知道的。而decorator的目的是包装一个对象并在运行时添加一些功能（为什么我不能用cor这样做呢？）。将COR（用于构造能够在一个链中一起处理请求的多个对象）设置为Behavior真的有意义吗？看起来不应该是structure吗？此外，这是否真的使修饰符（用于封装某些行为并在以后将其附加到某个给定对象）成为结构化？看起来不应该是behavior吗？

Answer 1

我认为链接的（规范的）线程中的答案大多是好的，它们的组合给出了这两种设计模式相当完整的图景；但是也许书中的一些内容和一些不同的术语也会有用。

提到的一个概念是，装饰器是加法的。每个装饰员处理每条消息。这意味着基数为两个或更多。有一个基本行为，客户端希望用一个或多个附加行为来增强，因此至少有两个行为。

责任链在书中被描述为一个或更少的行为。多个链接处理一个消息的可能性很容易想象，但书中没有提到。基数是0到1。

但最大的区别在于组合对象的实例化位置。通常，装饰器是由客户机直接实例化的，因为客户机确切地知道它想要在一些基本行为周围包装哪些增强。当客户端发出请求时，它显式地知道接收方，因为它在发送请求之前将它们包装在一起。

一条责任链对客户来说是看不见的。

发出请求的对象不知道谁将处理它-我们说请求有一个隐式的接收者。

这导致了客户机调用CoR而不是decorator的最大原因：因为客户机没有足够的信息来选择decorator。CoR是在其他地方配置的，客户机不知道有哪些可供选择的处理程序可用，甚至不知道它正在html" target="_blank">调用的处理程序是链的一部分。

装修者受益于一个更聪明的客户。责任链是配置的产物。

实现CoR的另一个令人信服的原因是当您的应用程序已经设计成某种形式的层次结构或树结构时。在对象之间已经有“后继”链接的情况下，添加责任部分相对简单，因为链已经在那里了。GoF不止一次地注意到CoR如何与复合模式很好地工作，因为后者为CoR提供了可以搭载的链接。

我相信这也可能是将CoR归类为一种行为模式的原因。在对象树已经存在的情况下（这是相当常见的），实现COR不需要结构上的更改。它纯粹是对先前存在的结构的行为改变。另一方面，一个新的装饰器总是引入一个新的构图关系，这是根据GoF类别的结构变化。