12

我正在实施责任链模式。

我有不同的策略可以组合在一个列表中，我有一个处理器来处理策略列表。每个策略都可以处理 CustomInput，并且可以选择是否也应处理其余策略。

interface Policy {    
  public boolean process(CustomInput input);    
}

interface Processor {    
  public void process(List<Policy> policies, CustomInput input)    
}

我打算实现处理器循环遍历策略列表并检查每个策略的布尔结果以了解是否继续执行其余策略。

我的同事建议将下一个策略传递给每个策略，并让他们调用（或不调用）下一个策略（例如 FilterChain 所做的）。

我的问题如下：

在第二个解决方案（将下一个策略传递给当前正在处理的策略）中，我在循环每个策略并检查其结果方面看不到任何好处吗？

4

3 回答 3

3

你能不能实现一个允许两个组件都有部分控制的中途解决方案？

interface Policy {
  public Policy process(CustomInput input, Policy defaultNext);
}

process然后可以默认返回defaultNext，除非它有自己的选择。

于 2013-12-03T15:29:53.107 回答
1

传递下一个的想法对我来说毫无意义。所以我想要一个链：

A - B - C - D

C如何知道D？如果它在 C 的代码中，那么对链的任何更改都将是一个巨大的麻烦来实现。

链需要遵循一些已经存在的其他路径，例如响应者在向其各自的父级（四人帮中的示例）提出帮助请求时所做的那样，或者您需要构建链，这就是为什么在 Go4 部分的底部，他们提到复合模式是自然出现的帮凶。

另请注意，执行责任链的主要原因之一是可能对项目进行操作的类型不同。这使得用 Java 中的接口实现它是完美的。

回答您的主要问题：在这种情况下使用责任链的好处有两个：1.您不是在制作一个知道实现目标可能发生的所有事情的上帝对象（政策的成功构建） , 和 2. 你不必输入很多丑陋的检查代码来查看何时到达终点，因为无论谁处理它，不调用它的继任者，都会提示完成项目的返回。

于 2013-12-03T16:04:27.160 回答
1

我正在实施责任链模式。

并不真地。您同事的建议实际上是 GoF 如何定义责任链。

链中的第一个对象接收请求并处理它或将其转发给链上的下一个候选对象，这同样...链上的每个对象共享一个通用接口来处理请求和访问其链上的后继对象. （第 224 页）

责任链可以简化对象互连。与对象保持对所有候选接收者的引用不同，它们保持对其后继者的单个引用。（第 226 页）

显然，CoR 被定义为单链表。你所描述的更像是中介者模式，你Processor扮演中介者的角色。权衡是集中控制与分散控制。

它集中控制。中介者模式用交互的复杂性换取中介者的复杂性。因为中介者封装了协议，所以它可能比任何单独的同事都复杂。这会使调解器本身成为难以维护的整体。（第 277 页）

如果您确信Processor除了迭代列表并检查布尔值之外，它永远不会做更多的事情，那么我认为您的设计是合理的。危险在于Processor可能会获得与特定CustomInputor相关的“特殊”逻辑Policy。这是神级的滑坡。

于 2018-10-22T15:48:52.750 回答