设计模式-行为型

一. 责任链模式

这种模式中,有发送者和接收者。通常,每个接收者都包含对另一个接收者的引用,形成一条链,如果一个接收者不能处理该请求,那么它会把相同的请求传给下一个接收者,依次类推。

这种模式将请求的发送者和接收者解耦,但是不能保证请求一定被接收。

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

这种模式和装饰者模式有一定相似的地方。

二. 命令模式

根据菜鸟教程的描述,“在软件系统中,行为请求者与行为实现者通常是一种紧耦合的关系,但某些场合,比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合适”。

对于这个描述,我现在的理解不深。我理解的是,将一个请求用一个对象进行封装,相当于在请求的发起者和请求之间加多一层,以便将请求者与请求进行解耦。

三. 解析器模式

这个看不太明白,感觉没有应用的场景。

四. 迭代器模式

对这个理解的也不深,感觉用的也不多。

五. 中介者模式

用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类,该类通常处理不同类之间的通信,并支持松耦合,使代码易于维护。

具体的做法是将交联型(网状)的关系转化为星型关系,1、系统中对象之间存在比较复杂的引用关系,导致它们之间的依赖关系结构混乱而且难以复用该对象。 2、想通过一个中间类来封装多个类中的行为,而又不想生成太多的子类。缺点可能是中介者会庞大,变得复杂难以维护。具体的应用有mvc中的c的作用。

六. 备忘录模式(应用比较少?)

主要解决:所谓备忘录模式就是在不破坏封装的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样可以在以后将对象恢复到原先保存的状态。

何时使用:很多时候我们总是需要记录一个对象的内部状态,这样做的目的就是为了允许用户取消不确定或者错误的操作,能够恢复到他原先的状态,使得他有"后悔药"可吃。

如何解决:通过一个备忘录类专门存储对象状态。

关键代码:客户不与备忘录类耦合,与备忘录管理类耦合。

应用实例: 1、后悔药。 2、打game时的存档。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、数据库的事务管理。

优点: 1、给用户提供了一种可以恢复状态的机制,可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装,使得用户不需要关心状态的保存细节。

缺点:消耗资源。如果类的成员变量过多,势必会占用比较大的资源,而且每一次保存都会消耗一定的内存。

七. 观察者模式
当对象间存在一对多关系时,则使用观察者模式(Observer Pattern)。比如,当一个对象被修改时,则会自动通知它的依赖对象。观察者模式属于行为型模式。应用是mvc中的事件机制。

八. 状态模式
将一个状态封装为一个对象(状态对象),这个对象会依赖于持有该状态的对象。状态对象有一个或多个方法改变持有状态的对象的行为。应用有: 状态机,行为树的动作节点等。

九. 空对象模式
to be continued……

十. 策略模式

意图:定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决:在有多种算法相似的情况下,使用 if...else 所带来的复杂和难以维护。

何时使用:一个系统有许多许多类,而区分它们的只是他们直接的行为。

如何解决:将这些算法封装成一个一个的类,任意地替换。

关键代码:实现同一个接口。

应用实例: 1、诸葛亮的锦囊妙计,每一个锦囊就是一个策略。 2、飞机game里面的bullet。

优点: 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

缺点: 1、策略类会增多。 2、所有策略类都需要对外暴露。

十一. 模板模式
to be continued……

十二. 访问者模式
to be continued……

to be continued