Design patterns 责任链中的HashMap是对模式的滥用吗？

我已经看到CoR模式的一个示例实现，它使用HashMap作为沿着链传递的对象，可能通过处理程序向其添加新内容；代码的概要如下：

class HandlerImpl implements Handler {

     Handler next;

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

很容易使用，因为处理程序可能会使用新信息增强

上下文

，这些信息可以由后续处理程序使用，而无需重复代码。另一方面，处理程序变得相互依赖——它们仍然是松散耦合的，但它们的顺序变得越来越重要

这代码有气味吗？如果我们发现在不向上下文对象补充新信息的情况下无法使用CoR模式，那么在这种情况下应该使用什么样的模式？

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

这样，每个处理程序就其需要/产生的数据而言是紧密耦合的（并且是显式的），但就产生和使用该数据的内容而言是松散耦合的

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

• 你想做什么
• 您使用的是哪种语言/平台（它有不变的推力吗？它有静态类型和泛型吗？）

---

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

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