Question

我已经看到使用HashMap作为向下传递的对象的CoR模式的示例实现，可能是处理程序将新内容添加到其中;以下代码的大纲：

class HandlerImpl implements Handler {

     Handler next;

     void handle(HashMap context) {
         // do handler logic, perhaps adding new stuff to "context"
         if (next != null)
             next.handle();
     }
 }

使用起来很诱人，因为处理程序可以使用后续处理程序可能使用的新信息来增强context，而无需重复代码。另一方面，处理程序变得彼此依赖 - 它们仍然松散耦合，但是，它们的顺序变得越来越重要。

这个代码闻起来了吗？如果我们发现我们不能使用CoR模式而不用新信息补充上下文对象，那么在这种情况下使用的模式是什么？

Answer 1

这取决于你的“处理程序”应该做什么。另一种方法是将其更改为“管道”，声明它需要什么输入，以及它的输出。输出可以是相同的类型 - 可能是对输入对象的修改 - 或者它可能是一些转换。这种转变可以只是添加信息，或者做一些完全不同的事情。如果只需要添加信息，可以使用合成相当容易地完成。

这样每个处理程序就它需要/产生的数据紧密耦合（和显式） - 但它在生成和消耗的方面松散耦合那个数据。

基本上，“最佳方法”取决于：

你想做什么
您正在使用什么语言/平台（它是否具有不可变的推力？它是否具有静态类型和泛型？）

Answer 2

我不认为在链中传递上下文是违反模式的。

servlet过滤器通常用作CoR模式的示例，过滤器可以在共享请求对象上自由添加/删除属性，甚至可以将请求包装在新对象中，以拦截后续执行的任何操作过滤器或servlet。

HashMap是一个滥用这种模式的责任链吗？

2 个答案: