设计模式读书笔记内容介绍

设计模式读书笔记内容介绍

中介者模式

名称:中介者模式(mediator)、调停者模式

问题:

将系统面向对象划分为许多独立对象可以增强复用,但对象间的交互却又带来关联降低复用性(矛盾对立统一)。假设如下情景:一个输入框、按钮联动的对话框,输入某个值,其他选择按钮应当不可用,另一方面,如果选择某个选择按钮,那么应当不允许输入此范围以外的值。不同的对话框有(以上)不同的依赖关系,必须定制对话框组件反映这种依赖关系,而涉及的类(对象)很多,如果用生成子类的办法会导致冗长。

解决:

将集体行为封装在一个中介者中,它负责控制、协调对象间的联动、依赖关系,使得对象间的联系通过中介者来执行,仅仅知道有中介者而不知道其他对象,减少耦合。

效果:

减少了子类对象的数量、减少耦合,简化了对相间的协议,对对象间如何进行了抽象。可以使注意力从对象转移到对象间的交互上来。但是会使几种对象难以维护(这个似乎是本质上这类问题就存在的复杂性)。

:

设计模式读书笔记内容介绍

备忘录模式

名称:备忘录模式、快照模式(snapshot)、Token模式

问题:

典型问题就是如何支持undo类操作。例如:一个图形编辑系统需要纪录图形对象的操作移动状态。一般情况下,我们采用一个称作ConstrainSolver的系统来解释对象间的相互约束关系。但是ConstrainSolver接口不足以精确逆转它对其他对新的作用,我们也不能够将ConstrainSolver内部实现暴露给取消操作机制。

解决:

通过建立一个memoto对象来存储另一个对象(源发器)在瞬间的内部状态,需要设置源发器的检查点时,取消操作机制会向源发器请求一个备忘录,源发器用当前状态信息初始化该备忘录,只有源发器可以存取备忘录。我们的图形编辑系统的问题可以这样解决:

移动操作时,编辑器向ConstrainSolver请求一个备忘录;

ConstrainSolver存储内部状态到备忘录对象,返回给编辑器;

需要撤销操作时,编辑器将原先的备忘录给ConstrainSolver对象,由后者进行恢复内部状态的操作。

效果:

保持封装边界,将复杂的源发器的内部信息对其他对象隐蔽;简化了源发器;但是代价可能很高(消耗内存/辅存等资源)

:

设计模式读书笔记内容介绍

观察者模式

名称:观察者模式(Observer)、发布/订阅模式(Publish/Subscribe)、模型/视图(Model/View)模式、源/监听器模式(Source/Listener)、从属模式(Dependents/依赖模式

问题:

许多应用将数据同表现层分离,可以复用数据对象和表现对象。一旦数据改变,表现层应当改变,例如可能柱状图需要改变、扇形图也需要改变。我们也没有必要将受到影响的对象限制,可以是多个。如何实现呢?

解决:

观察者模式解决此问题。数据作为目标,其他表现层对象为观察者,一旦数据改变,其他的观察者得到通知并做出响应。每个观察者必须查询目标的状态并进行同步。(具体见图)

效果:

目标同观察者间的抽象耦合,支持广播通信(所有观察者知道通知)。但是目标的简单更新又可能引起观察者的巨大变化。

图:

设计模式读书笔记内容介绍

状态模式

名称:状态模式、状态对象模式(Objects for States

问题:

考虑一个TCP连结类的多个状态(已连结、监听、已关闭、正连结)等,如何在收到其他对象的请求时候根据自身的状态进行反映?这就用到状态模式。

解决:

TCPState抽象类表示连结的状态,声明针对状态的操作,然后由状态的子类实现具体的状态和相应的操作。而TCP连结对象维护一个状态类实例,将所有接收到的请求交给状态类实例来实现。这样一旦状态改变,TCP连结类就会改变具体的状态类实例,从而针对性做出反应。

效果:

将与状态相关的操作局部化。使得装套转换显示化。状态对象可以被共享。

图:

设计模式读书笔记内容介绍

策略模式

名称:策略模式、政策模式(Policy

问题:

考虑一个购物系统中的价格计算,简单的是单价乘以数量,但是可能有不同的折扣(例如有些3%的折扣,有些无折扣),而且折扣可能不断随着时间改变,如何实现呢?

解决:

将环境和折扣行为分开,环境类负责维护和查询行为类,各种算法具体在称为算法类中实现。出现新的折扣仅需要在策略类中实现。

效果

提供了可重用的算法功能;提供了一种替代继承的方法(不用继承环境类而仅需要修改、新增策略类)。消除了设计中的复杂的条件语句选择语句。但是增加了对象的数量、增加了策略类同环境类之间的通信开销,而且客户被迫要知道策略类。

图:

设计模式读书笔记内容介绍

 

模板方法模式

名称:模板方法模式

问题:

考虑一个提供ApplicationDocument类的应用框架,ApplicationopenDocument打开Document。但是Document类型很多,不可能在一个Document中实现。

解决:

openDocument视作模板方法,用一些抽象操作定义一个方法,而子类重新定义这些方法。(这里的子类是指ApplicationDocument的子类)

效果:

代码复用,提取了类库中公共行为。导致了反向控制(由父类操纵子类的方法)

模板类方法极其普遍,几乎所有的框架都有应用实例。

图:

设计模式读书笔记内容介绍

访问者模式

名称:访问者模式

问题:

考虑一个编译系统将源程序看作一个抽象语法树,编译器需要在此树进行分析操作,大多要求对不同的节点进行不同的操作,但是将不同的操作分散到不同节点的类中会导致混乱。

解决:

将每一个类的相关操作封装到独立对象(Vistor),在遍历抽象语法树时候将此对象传递给正在访问的节点元素。该元素向访问者发出包含自身类信息的操作请求,且将元素作为参数,由访问者来为元素执行操作。

效果:

使得易于增加新的操作,集中了相关的操作分离类无关的操作。但是,很困难新增元素。可以通过类层次进行访问。同时产生了累积状态,且访问者可能会破坏元素的内部状态,破坏封装。

图:

设计模式读书笔记内容介绍