标签：请求 GUI GoF 命令 Command 组件 MenuItem 设计模式 行为

职责链模式（Chain Of Responsibility)

如果你的类为了实现某种功能，需要调用一批组件中的一个（或多个），并且它不知道在什么情况下调用什么组件，这时不妨让组件串成一个链，链中的每个组件按顺序自己检测自己能否提供这个功能，这就是职责链模式。

动机

Web服务器往往提供某种对请求进行拦截、检查、处理的机制，Web服务器往往提供一种名为Filter或Interceptor组件来实现拦截。但Web服务器设计之初，并不知道在什么情况下使用哪个Filter进行拦截，这是特定于你的业务需求的，这种代码不可能内化在Web服务器的逻辑中。

Servlet API中的Filter就是用来将Web服务器和具体拦截逻辑解耦的组件，多个Filter组成一个链，对于每一个到来的请求，Web服务器只需要将请求送到Filter链上，每一个Filter自己检测对于该请求是否拦截、拦截后做什么、是否让请求在Filter中继续向后传播。

如果你的类为了实现某种功能，需要调用一批组件中的一个（或多个），并且它不知道在什么情况下调用什么组件，这时不妨让组件串成一个链，链中的每个组件按顺序自己检测自己能否提供这个功能，这就是职责链模式。职责链模式的主要优点在于，解耦了功能的调用者和提供者。

适用性

1. 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
2. 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
3. 可处理一个请求的对象集合应被动态指定。

结构

参与者

• Handler：用于处理请求的组件的接口，代表职责链中的一个处理单元。
• ConcreteHandler：具体的处理组件。
  • 可以访问后继处理器
  • 需要能够判断自己是否能处理请求
  • 在能处理请求并已经处理的情况下，它可以自己决定是否将请求传递给后继处理器
• Client：职责链的调用者，它接收请求，发送给职责链，它无需知道谁会实际处理请求

命令模式（Command）

当一个需要被复用的组件在某些时刻需要做一些事，但它不知道要做的事的任何细节，可以使用命令模式，将这些要做的事抽象成命令，由系统中的其它部分来实现，组件只发送一个请求到这个命令即可。

动机

考虑一个GUI程序的菜单栏。

你使用的GUI库将每一个菜单栏上的项目抽象为一个MenuItem，GUI库肯定不知道MenuItem被选中时应该做什么操作，这是特定的应用来决定的，而你的应用又不知道MenuItem什么时候被选中，这是GUI库才知道的。

GUI库可以提供一种Command接口，它代GUI库中某些事件触发（比如按钮按下、菜单项被选中）时该执行什么操作，GUI库的使用者来创建实现Command接口的类并传递给GUI组件。

如下图，GUI组件MenuItem持有一个我们创建的Command，在它被点击时，MenuItem会调用我们的Command的Execute方法，来执行我们期望的命令。

Command可以持有应用中的任何用于实现功能的组件，比如下面的PasteCommand，它的功能是将剪贴板上的内容粘贴到文档中，所以它必须持有Document组件。

下面的图片比较有意思，某些MenuItem被点击后需要执行的命令可能比较复杂，可以由多个Command对象复合而成，我们完全可以建立一个MacroCommand，它持有多个Command对象，并顺序执行它们，这是不是结构型设计模式中的“组合模式”?

其实上面的图片向我们揭示了命令模式的另一个好处，即将要执行的操作抽象成命令，我们可以在任何需要它的地方复用它。

考虑下，AWT、Swing和Android开发中哪里用到了命令模式呢？有很多地方哦

当一个需要被复用的组件在某些时刻需要做一些事，但它不知道要做的事的任何细节，可以使用命令模式，将这些要做的事抽象成命令，由系统中的其它部分来实现，组件只发送一个请求到这个命令即可。

适用性

1. 像上面讨论的MenuItem对象那样，抽象出待执行的动作以参数化某对象。
2. 在不同的时刻指定、排列和执行请求。
3. 支持取消操作。

• Command可以在执行操作前记录下当前状态，并提供UnExecute方法，恢复到之前的状态
• 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。

结构

参与者

在此部分，给出该设计模式中的关键组件，为了便于练习，我不会将这里所述的组件与上面示例中的组件一一对应，你需要自己思考并对号入座。如果不确定，再往下一点就是答案。

• Command：命令接口
  • 声明执行操作的方法
  • 定义是否支持取消
  • 定义是否进行持久化
• ConcreteCommand：具体的命令实现
• Invoker：Command的调用者
• Receiver：被Command所持有，是执行Command中操作必要组件，也可以看作操作的最终接收者
• Client：负责创建命令，给命令设定接收者和调用者

Command: Command
ConcreteCommand: PasteCommand、MarcoCommand
Invoker: MenuItem
Receiver: Document
Client: Application

解释器模式（Interpreter)

标签：请求,GUI,GoF,命令,Command,组件,MenuItem,设计模式,行为
来源： https://www.cnblogs.com/lilpig/p/16412927.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。