问题标签 [chain-of-responsibility]

责任链模式与装饰者模式有何不同...？

我已经看到有关此模式的一些问题，但我正在尝试深入了解有关此设计模式的更多信息。这方面的任何资源，专家评论他们倾向于使用这种模式的场景以及要避免的场景以及一些现实世界的例子在这方面将非常有帮助。我不是在寻找什么是 COR 类型，而是在寻找专家的一些高级评论。这将有助于我下次更负责任地应用这种模式。

我正在尝试重写一些代码以解决一些耦合问题并使其更容易在将来修改。

现在，我在基类中有一个静态工厂方法，可以根据情况选择适当的实现。该决定基于专业化程度：

虽然类型 A 和 B 都可以处理这个问题，但 B 是专门为这种情况设计的，是正确的选择。

因此，基类与所有实现紧密耦合，并且在创建新的专用实现时必须重写此方法。

我正在考虑使用责任链模式来打破这种耦合。但是，我看不到确保执行最合格的实现的方法。如果我把它交给实现来做出这个决定，我不能保证它们会按专业化的顺序被查询而不会遇到相同的耦合问题。

有没有处理这种情况的模式或方法？ （我最好的猜测会阻碍部署；我会把它放在我的后兜里，以免每个人都说“是的，这是唯一的方法！”）

假设我有一个不可复制的类Foo，并且它的一个构造函数恰好接收到对Foo.

编译器认为这是一个复制构造函数，而它所做的事情与复制完全无关（因此赋值运算符被禁用）。

以这种方式定义构造函数是否有任何危险，或者我应该人为地更改它的签名，例如使用指针而不是引用，或者添加一个强制性的虚拟参数？

这是一些上下文（可能不需要理解/回答我的问题）。

我有一个自己编写的类库，用作用户代码和另一个库之间的连接。另一个库提供了一项服务，为简洁起见，我将其称为frobnicate。用户代码可能如下所示：

我想支持用户对象的层次结构：每个对象都包含在另一个对象（它的父对象）中，而有几个（在我的例子中是 5 个）包含所有其他对象的顶级对象。

每个对象都有一个日志文件；我希望每个调用都记录在几个日志文件中，沿着包含层次结构向上直到一个顶级对象。

我以这种方式实现了它：

我提出这个问题是因为几天前我在这里问了另一个问题。
我必须解决一个特定问题，在收到两次回复后，我意识到两种模式可以帮助解决该问题（以及任何其他类似问题）。

1. 责任链
2. 战略

我的问题是：

这些模式之间究竟有什么区别？

有没有一种设计模式可以帮助我避免DoThisStepFirst()在许多方法中重复？

编辑 1：可以这么说，这是一个人为的例子。
我的实际实现包括带有参数的方法签名和每个方法中的重要操作。

编辑2：

• @Marc Gravell 建议面向方面编程。是的，这可能对我有帮助。
• 我还认为责任链模式在这里也可能对我有所帮助。

@Charlie Martin 想了解有关该计划的更多信息。所以这就是我真正想要做的。

• 我正在尝试设置一个测试工具来针对“ m ”控制器和“ n ”控制器方法的 ASP.NET MVC 2 应用程序运行。
• MVC 应用程序与 SessionState 紧密耦合。由于各种原因，我无法模拟 SessionState。
  • 所以在DoThisStepFirst()方法内部，我想初始化 SessionState。
  • 在初始化 SessionState 之后，我想继续使用指定的方法（这就是为什么我怀疑我可能正在寻找“责任链”设计模式）。

我在开发过程中有一个简单的 CRUD 网站，几乎完成了。我被要求重构代码，但这次使用struts 2和commons chain。我阅读了几个这样的网站，但无法确切知道这两个（struts 2 和 commons 链）在我的项目中扮演的关键角色。我还被要求不要担心本教程中的 struts 标签，因为可以使用我之前制作的代码。

谁能给我一个见解。谢谢

注意：一天前我开始看到关于struts 2

我使用设计模式已经有一段时间了，并且一直将其称为“责任链模式”，但现在我意识到存在差异，这样做可能不合适。所以我的问题是 1，“下面是这种模式的一个实例，还是应该将其称为其他东西？”，以及 2，“我有什么理由更喜欢传统方式吗？”。

在开发软件时，我经常使用以下模式。我有一个定义functor的接口，类似这样。

这些通常是搜索、过滤或处理类；通常类似于Comparator。实现方法通常是功能性的（即无副作用）。最终，我发现自己创建了一个如下所示的接口实现：

它也不总是布尔值——我也将这种模式与可变对象一起使用——但总是存在短路条件（例如返回真，字符串为空字符串，设置标志等）。

到目前为止，我通常将其称为“责任链”模式，考虑到从基类继承的问题是一个实现细节。但是，今天我意识到了一个重要的区别：链条上的物体不能打断链条的其余部分。实现没有办法说“这是错误的，我可以保证它在任何情况下都是错误的”（nb：短路仅在 上true）。

那么，这应该被称为责任链模式以外的东西吗？在使用这种方法而不是让实例传递消息的传统方法时，我是否应该考虑任何顾虑或问题。

我很难解决这个问题，我希望有人可以帮助我。

我有一个责任链类，我想知道我是否可以（并且想要）将它实现为 LinkedList 类的派生类。从本质上讲，责任链当然是一个链表，但我不确定从 LinkedList 派生在这里是否真的合适，因为每个实现的方法都需要能够在后续方法中调用相同的方法，如果当前一个失败。

你能实现类似的东西public class MyHandler : LinkedList<MyHandler>吗？这似乎是一个递归定义，但编译器并不认为这是一个问题。

有人对此有任何见解吗？

我有一个名为 ChainHandler 的抽象类和 ChainHandler 的许多实现。

其他程序员将编写该 ChainHandler 的其他实现。

我的程序实现了责任链设计模式。

ChainHandler 的每个具体实现都实现了一个句柄方法。

如果一个处理程序可以处理“a”，它会处理它并且链停止。如果不是，则将“a”传递给下一个处理程序，直到它到达链的末尾。

我希望每个具体的处理程序都有一个它能够处理的所有“a”的列表。但我不想让具体类开发人员记住将其写入成功列表。

有没有优雅的方法呢？

我最好的想法是：

1 - 在具体类中将句柄方法更改为受保护，使其返回布尔值并将名称更改为内部句柄；

2 - 将抽象类的句柄方法更改为公共，并调用内部句柄。成功后，它将对象添加到列表中。