对拦截器模式的思考

拦截器模式在很多场合会见到，本质上讲它不属于基础24种设计模式的一种，但从设计实现角度看，责任链模式可以很好得实现拦截器。比如web服务器的filter、structs2框架中的interceptor、flumn的interceptor等等。
很多时候，我们会过度迷恋设计模式，我以为，适合拦截器设计的场合如下：
1.各个拦截器彼此之间独立
  拦截器彼此之间不应当有关联，即彼此无耦合。通常连接器（责任链上的节点）对某个对象的处理都是从自身视角看，只关心自己的处理逻辑。彼此独立就意味着，拦截器配置的先后顺序无关。
2.拦截器自身无状态
  拦截器对对象的处理不应当关心这次处理的对象和上一个对象之间的联系，当然，如果一定有这样的需求，拦截器也可以做成有状态的，此时却加重了调用者的设计负担。拦截器之间的彼此独立特性和自身的无状态特性应当是相辅相成的
3.拦截器执行幂等
  拦截器对某个对象拦截处理应当是幂等的，即多次执行和一次执行的效果相同。因此，即使配置同一个拦截器多次，也不会影响整个架构。事实上，一般的拦截器处理结果都会保存到map中，而map.put本身就是幂等的

为了设计模式而设计模式是愚蠢的事情；同样为了完美的模式而选择模式也是无谓的。

structs2的第一个拦截器在我看来是反模式的，但却很好得完成了任务