终于来到了行为型模式的学习,这一部分是最多的,慢慢啃吧
命令模式
描述:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操作。

对请求排队或记录请求日志,以及支持可撤销操作时,“行为请求者”和“行为实现者”紧耦合是不合适的。
命令模式用来解决“行为请求者”和“行为实现者”紧耦合的问题。
命令模式的4个角色
Command(命令接口):用来声明操作的接口。
ConcreteCommand(具体命令类):将一个接收者对象绑定于一个动作,调用接收者相应的操作。
Receiver(命令执行对象):知道如何实施与执行一个请求相关的操作,任何类都可能作为一个接收者。
Invoker(命令请求对象):用于执行这个请求,可以动态的对命令进行控制。
1 | //Receiver |
主程序
1 | public class Command { |
总结命令模式的优点
- 能较容易地设计一个命令队列
- 在需要的情况下,可以较容易地将命令记入日志
- 允许接收请求的一方决定是否要否决请求
- 能容易地实现对请求的撤销和重做
- 由于添加新的具体命令类不影响其他类,因此增加新的具体命令类很容易
最关键的优点是:把请求一个操作的对象与知道怎么执行一个操作的对象分隔开
责任链模式
描述:为解除请求的发送者和接收者之间耦合,而使多个对象都有机会处理这个请求。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它。

责任链模式的2个角色
Handler(抽象处理者):它定义了一个处理请求的接口,一般设计为抽象类,由于不同的具体处理者处理请求的方式不同,因此在其中定义了抽象请求处理方法。因为每一个处理者的下家还是一个处理者,因此在抽象处理者中定义了一个抽象处理者类型的对象,作为其对下家的引用。通过该引用,处理者可以连成一条链。
ConcreteHandler(具体处理者):它是抽象处理者的子类,可以处理用户请求,在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法,在处理请求之前需要进行判断,看是否有相应的处理权限,如果可以处理请求就处理它,否则将请求转发给后继者;在具体处理者中可以访问链中下一个对象,以便请求的转发。
纯的责任链模式:
一个具体处理者对象只能在两个行为中选择一个:要么承担全部责任,要么将责任推给下家,不允许出现某一个具体处理者对象在承担了一部分或全部责任后
又将责任向下传递的情况
一个请求必须被某一个处理者对象所接收,不能出现某个请求未被任何一个处理者对象处理的情况
不纯的责任链模式:
允许某个请求被一个具体处理者部分处理后再向下传递
或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求
而且一个请求可以最终不被任何处理者对象所接收
1 | class Request { |
主程序
1 | public class Responsibility { |
责任链有什么好处?
当客户提交一个请求时,请求时沿链传递直至有一个ConcreteHandler对象负责处理它,这就使得接收者和发送者都没有对方的明确信息,且链中的对象自己也不知道链的结构,结果是责任链可以简化对象的相互连接,它们仅保持一个指向其后继者的引用,而不需要保持它所有候选接收者的引用。可以随时地增加或修改处理一个请求的结构,增强了独享指派职责的灵活性。
但一个请求有可能到了链的末端都得不到处理,或者因为没有正确配置而得不到处理。
参考资料: