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

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

中介者模式

名称：中介者模式（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%的折扣，有些无折扣），而且折扣可能不断随着时间改变，如何实现呢？

解决：

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

效果

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

图：

 

模板方法模式

名称：模板方法模式

问题：

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

解决：

将openDocument视作模板方法，用一些抽象操作定义一个方法，而子类重新定义这些方法。（这里的子类是指Application和Document的子类）

效果：

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

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

图：

访问者模式

名称：访问者模式

问题：

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

解决：

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

效果：

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

图：