其他分享
首页 > 其他分享> > GoF设计模式——行为型设计模式

GoF设计模式——行为型设计模式

作者：互联网

职责链模式（Chain Of Responsibility)

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

动机

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

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

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

适用性

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

结构

img

参与者

命令模式（Command）

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

动机

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

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

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

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

img

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

img

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

img

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

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

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

适用性

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

结构

img

参与者

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

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

解释器模式（Interpreter)

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