职责链模式 vs 装饰者模式

本是古典何须时尚 2023-10-10 15:19 10阅读 0赞

## 职责链模式（行为型） ##

**定义**：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。缺点是性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候， 性能是一个非常大的问题。

![951fe96c91db48d3a29ff795068999aa.png][]

**主要解决**：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。

**何时使用**：在处理消息的时候以过滤很多道。

**如何解决**：拦截的类都实现统一接口。

**关键代码**：Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。

**应用实例**： 1、红楼梦中的"击鼓传花"。 2、JS 中的事件冒泡。 3、JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。

**优点**： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。

**缺点**： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。

**使用场景**： 1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。

> **关键点**：当客户提交请求时，请求是沿链传递直至有一个ConcreteHandler对象负责处理它。这使得接受者和发送者都没有对方的明确信息，且链中对象自己也并不知道链的结构。职责链可以简化对象的相互连接，它们仅需要保持一个指向其后继者的引用，而不需要保持它所有的候选接收者的引用。可以随时的增加或者修改处理一个请求的结构，增强了给对象指派职责的灵活性。

## 装饰VS职责链两者相同点以及不同点 ##

**相同点**：都能对对象的处理进行增强，都是使用父子链（巧用封装继承多态）。

**不同点：**实现逻辑不同。装饰是通过子类添加功能职责；职责链模式的子类实现的是同一个工作不同部分。

**职责链模式:只关心被调用者之间的调用传递。**

**装饰器模式:它不关心外界如何调用，只注重对对象功能的加强，装饰后还是对象本身。**

参考文章原链接：

[(80条消息) 【设计模式】——装饰模式VS职责链模式\_Mandy\_i的博客-CSDN博客][80_ _VS_Mandy_i_-CSDN]

[951fe96c91db48d3a29ff795068999aa.png]: https://img-blog.csdnimg.cn/951fe96c91db48d3a29ff795068999aa.png
[80_ _VS_Mandy_i_-CSDN]: https://blog.csdn.net/jiadajing267/article/details/106889562?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166789639416800180647410%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=166789639416800180647410&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-1-106889562-null-null.142%5Ev63%5Econtrol,201%5Ev3%5Eadd_ask,213%5Ev1%5Et3_control2&utm_term=%E8%A3%85%E9%A5%B0%E6%A8%A1%E5%BC%8F%E4%B8%8E%E8%81%8C%E8%B4%A3%E9%93%BE%E6%A8%A1%E5%BC%8F&spm=1018.2226.3001.4187