设计模式之职责链模式(下)

3)纯的职责链模式

要求一个具体处理者对象要么承担全部责任要么将责任推给下家

不允许出现某一个具体处理者对象在承担了一部分或全部责任后又将责任向下传递的情况;

在纯的职责链模式中,要求一个请求必须被某一个处理者对象所接收,不能出现某个请求未被任何一个处理者对象处理的情况。

4)不纯的职责链模式

不纯的职责链模式中允许某个请求被一个具体处理者部分处理后再向下传递,或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求,而且一个请求可以最终不被任何处理者对象所接收。

每一级组件在接收到事件时,都可以处理此事件,而不论此事件是否在上一级已得到处理,还存在事件未被处理的情况。

5)总结
1.优点
  • 职责链模式使得一个对象无须知道是其他哪一个对象处理其请求,对象仅需知道该请求会被处理即可,接收者和发送者都没有对方的明确信息,且链中的对象不需要知道链的结构,由客户端负责链的创建,降低了系统的耦合度。

  • 请求处理对象仅需维持一个指向其后继者的引用,而不需要维持它对所有的候选处理者的引用,可简化对象的相互连接。

  • 在给对象分派职责时,可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责。

  • 在系统中增加一个新的具体请求处理者时无须修改原有系统的代码,只需在客户端重新建链即可。

2.缺点
  • 由于一个请求没有明确的接收者,那么就不能保证它一定会被处理,该请求可能一直到链的末端都得不到处理;一个请求也可能因职责链没有被正确配置而得不到处理。

  • 对于比较长的职责链,请求的处理可能涉及到多个处理对象,系统性能将受到一定影响,而且在进行代码调试时不太方便。

  • 如果建链不当,可能会造成循环调用,将导致系统陷入死循环。

3.适用场景

有多个对象可以处理同一个请求,具体哪个对象处理该请求待运行时刻再确定,客户端只需将请求提交到链上,而无须关心请求的处理对象是谁以及它是如何处理的。

在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。

可动态指定一组对象处理请求,客户端可以动态创建职责链来处理请求,还可以改变链中处理者之间的先后次序。

相关推荐

  1. 设计模式职责模式

    2024-04-04 15:10:02       41 阅读
  2. 设计模式 -职责模式

    2024-04-04 15:10:02       61 阅读
  3. 设计模式--职责模式

    2024-04-04 15:10:02       26 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-04-04 15:10:02       98 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-04-04 15:10:02       106 阅读
  3. 在Django里面运行非项目文件

    2024-04-04 15:10:02       87 阅读
  4. Python语言-面向对象

    2024-04-04 15:10:02       96 阅读

热门阅读

  1. WPS二次开发系列:WPS SDK初始化

    2024-04-04 15:10:02       43 阅读
  2. HTML中js简单实现石头剪刀布游戏

    2024-04-04 15:10:02       37 阅读
  3. Husky使用简明教程

    2024-04-04 15:10:02       40 阅读
  4. python将visio转换为 PDF 文件

    2024-04-04 15:10:02       32 阅读
  5. 小于电商开放平台-订单线下发货

    2024-04-04 15:10:02       35 阅读
  6. MySQL数据库下载及安装教程(Windows、Linux)

    2024-04-04 15:10:02       40 阅读
  7. 225.队列实现栈

    2024-04-04 15:10:02       31 阅读
  8. Day19.

    2024-04-04 15:10:02       38 阅读