CoR 和 Decorator 之间有什么区别？为什么 CoR 是一种行为模式？为什么Decorator是一种结构模式？
What is the difference between the CoR and the Decorator? Why is CoR a behavioral pattern? Why is Decorator a structural pattern?
This answer差不多把题的前半部分说清楚了
它说：
After reading the Gang of Four definitions, I'm not convinced there's
a real difference. (included for convenience)
- Decorator: Allows for the dynamic wrapping of objects in order to
modify their existing responsibilities and behaviours
- Chain of
Responsibility: Gives more than one object an opportunity to handle a
request by linking receiving objects together
Wikipedia fleshes them out a little, but some of it's kinda arbitrary.
Decorator is typically implemented as a Linked List. But I think
that's too low-level to be considered "part" of the pattern.
Chain of Responsibility links only handle data if it's their responsibility;
but determining responsibility and data handling are both part of behavior. Decorators can do this just as easily.
Decorator requires you to call the delegate.
A "pure" CoR link should only call the delegate if it doesn't handle the data. The first two attributes don't
really distinguish the patterns.
The second two do, but the way
Decorator and CoR are usually implemented don't enforce those
attributes--the designer just hopes no one writes a Decorator that
breaks the chain or a CoRLink that continues the chain after handling
the data.
两种模式的结构几乎相同。是什么迫使装饰者模式以这种方式实现？而不是有一个 ConcreteElement 和一些 Decorators，是什么阻止我让每个 Decorator 指向它正在包装的对象，当指向被包装的对象的指针是 null，然后做与 ConcreteElement 中发生的相同的事情？是什么让每个结构都特定于其模式？
另外，为什么它们在不同的类别中？此外，阅读其他答案here，看起来即使结构几乎相同，但意图不同。 CoR 旨在拥有几个可能处理请求的潜在对象，并且事先不知道将处理请求的对象。而装饰器旨在包装一个对象并在运行时添加一些功能（为什么我不能用 CoR 做到这一点？）。 CoR（旨在构建能够在链中一起处理请求的多个对象）为 behavioral 真的有意义吗？不应该是structural吗？此外，Decorator（旨在封装某些行为并稍后将其附加到某个给定对象）真的有意义吗？ structural？不应该是behavioral吗？
我认为链接（规范）线程中的答案大部分都很好，它们的组合给出了这两种设计模式的相当完整的图景；但也许从本书中获取更多信息以及略有不同的术语也可能有用。
提到的一个概念是装饰器是加法的。每个 Decorator 处理每条消息。这意味着基数为 2 或更多。客户希望通过一种或多种额外行为来增强一种基本行为，因此至少需要两种行为。
责任链在书中被描述为一种或更少的行为。多个链接处理一条消息的潜力很容易想象，但书中并未提及。基数是零到一。
不过，最大的区别在于组合对象的实例化位置。通常，装饰器由客户端直接实例化，因为客户端确切地知道它想要围绕某些基本行为包装哪些增强功能。当客户端发出请求时，它明确地知道接收者，因为它在发送请求之前将它们包装在一起。
客户看不到责任链。
The object that made the request has no explicit knowledge of who will handle it—we say the request has an implicit receiver.
这导致客户调用 CoR 而不是 Decorator 的最大原因：因为客户没有足够的信息来选择 Decorator。 CoR 在其他地方配置，客户端不知道哪些替代处理程序可用，甚至不知道它正在调用的处理程序是链的一部分。
修饰器受益于更智能的客户端。责任链是配置的产物。
实施 CoR 的另一个令人信服的理由是当您的应用程序已经设计为某种形式的层次结构或树结构时。在对象之间已经存在 "successor" 链接的情况下，添加 Responsibility 部分相对简单，因为 Chain 已经存在。 GoF 不止一次注意到 CoR 如何与复合模式很好地协同工作，因为后者为 CoR 提供了搭载链接。
我相信这也可能是将 CoR 归类为一种行为模式的原因。在对象树已经存在的情况下（这很常见），实现 CoR 不需要结构上的改变。这纯粹是对现有结构的行为改变。另一方面，一个新的Decorator总是引入一个新的组合关系，这是根据GoF类别的结构变化。
This answer差不多把题的前半部分说清楚了
它说：
After reading the Gang of Four definitions, I'm not convinced there's a real difference. (included for convenience)
- Decorator: Allows for the dynamic wrapping of objects in order to modify their existing responsibilities and behaviours
- Chain of Responsibility: Gives more than one object an opportunity to handle a request by linking receiving objects together
Wikipedia fleshes them out a little, but some of it's kinda arbitrary.
Decorator is typically implemented as a Linked List. But I think that's too low-level to be considered "part" of the pattern.
Chain of Responsibility links only handle data if it's their responsibility; but determining responsibility and data handling are both part of behavior. Decorators can do this just as easily.
Decorator requires you to call the delegate.
A "pure" CoR link should only call the delegate if it doesn't handle the data. The first two attributes don't really distinguish the patterns.
The second two do, but the way Decorator and CoR are usually implemented don't enforce those attributes--the designer just hopes no one writes a Decorator that breaks the chain or a CoRLink that continues the chain after handling the data.
两种模式的结构几乎相同。是什么迫使装饰者模式以这种方式实现？而不是有一个 ConcreteElement 和一些 Decorators，是什么阻止我让每个 Decorator 指向它正在包装的对象，当指向被包装的对象的指针是 null，然后做与 ConcreteElement 中发生的相同的事情？是什么让每个结构都特定于其模式？
另外，为什么它们在不同的类别中？此外，阅读其他答案here，看起来即使结构几乎相同，但意图不同。 CoR 旨在拥有几个可能处理请求的潜在对象，并且事先不知道将处理请求的对象。而装饰器旨在包装一个对象并在运行时添加一些功能（为什么我不能用 CoR 做到这一点？）。 CoR（旨在构建能够在链中一起处理请求的多个对象）为 behavioral 真的有意义吗？不应该是structural吗？此外，Decorator（旨在封装某些行为并稍后将其附加到某个给定对象）真的有意义吗？ structural？不应该是behavioral吗？
我认为链接（规范）线程中的答案大部分都很好，它们的组合给出了这两种设计模式的相当完整的图景；但也许从本书中获取更多信息以及略有不同的术语也可能有用。
提到的一个概念是装饰器是加法的。每个 Decorator 处理每条消息。这意味着基数为 2 或更多。客户希望通过一种或多种额外行为来增强一种基本行为，因此至少需要两种行为。
责任链在书中被描述为一种或更少的行为。多个链接处理一条消息的潜力很容易想象，但书中并未提及。基数是零到一。
不过，最大的区别在于组合对象的实例化位置。通常，装饰器由客户端直接实例化，因为客户端确切地知道它想要围绕某些基本行为包装哪些增强功能。当客户端发出请求时，它明确地知道接收者，因为它在发送请求之前将它们包装在一起。
客户看不到责任链。
The object that made the request has no explicit knowledge of who will handle it—we say the request has an implicit receiver.
这导致客户调用 CoR 而不是 Decorator 的最大原因：因为客户没有足够的信息来选择 Decorator。 CoR 在其他地方配置，客户端不知道哪些替代处理程序可用，甚至不知道它正在调用的处理程序是链的一部分。
修饰器受益于更智能的客户端。责任链是配置的产物。
实施 CoR 的另一个令人信服的理由是当您的应用程序已经设计为某种形式的层次结构或树结构时。在对象之间已经存在 "successor" 链接的情况下，添加 Responsibility 部分相对简单，因为 Chain 已经存在。 GoF 不止一次注意到 CoR 如何与复合模式很好地协同工作，因为后者为 CoR 提供了搭载链接。
我相信这也可能是将 CoR 归类为一种行为模式的原因。在对象树已经存在的情况下（这很常见），实现 CoR 不需要结构上的改变。这纯粹是对现有结构的行为改变。另一方面，一个新的Decorator总是引入一个新的组合关系，这是根据GoF类别的结构变化。