第25讲：设计模式总结

2006.10.23 李建忠

创建型模式

Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。

Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。

如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder，Prototype）。

 

结构型模式

Adapter模式注重转换接口，将不吻合的接口适配对接（适合于旧系统）

Bridge模式注重分离接口与其实现，支持多维度变化

Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系

Decorator模式注重稳定接口，在此前提下为对象扩展功能

Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系

Flyweight模式注重保留接口，在内部使用共享技术对对象存储进行优化

Proxy模式注重假借接口，增加间接层来实现灵活控制

 

行为型模式

Template Method模式封装算法结构，支持算法子步骤变化

Strategy模式注重封装算法，支持算法的变化

State模式注重封装与状态相关的行为，支持状态的变化

Memento模式注重封装对象状态变化，支持状态保存/恢复

Mediator模式注重封装对象间的交互，支持对象交互的变化

Chain Of Responsibility模式注重封装对象责任，支持责任的变化

Command模式注重将请求封装为对象，支持请求的变化

Iterator模式注重封装集合对象内部结构，支持集合的变化

Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化

Observer模式注重封装对象通知，支持通信对象的变化

Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作

 

模式之间的关系图

 

例说模式综合应用

我们以做一个文件分割器为例

刚开始做的时候我们并不知道应该用什么模式。

浏览

分割，把文件作二进制处理，拿到文件长度，和分割数量，然后顺序读取文件进行处理。

从设计层面来想，这样的设计是很粗糙的。能正常工作并不意味着能很好的工作。

假如现在提出几个需求：

1.程序没有通知，如果分割一个大文件，用户等了很久都不知道你在干什么，因此应该提供一个进度条。

2.发邮件的时候对文件分割器的需求比较大，我们希望在发邮件的时候监测到邮件太大就自动分割文件，分割同时发出一个协议文件，描述了分割的步骤和顺序，然后客户端拿到分割后的文件，再根据协议合并文件。这样文件分割器就应该适用于可复用的组件。

3.文件太大分割器会导致内存暴涨。问题在于代码中的

例如我们要把1G的文件分割成4份，这意味着一次就需要从硬盘上读200多M，这样对内存的需求就会暴涨。因此程序的算法还需要改进。

 

开始重构

第一步首先要分离耦合，把表现层与业务层分离。

整个算法放到Split函数里面。接下来表现层只需要实例化一个分割算法类即可。

这样界面和类库的代码就顺利解耦了。这样的话我们就可以把分割类库作为独立的dll被Outlook等应用程序调用了。

 

然后我们考虑，MyFileSplitter类库很可能会改变，特别是Split算法的改变频率可能更高。但是现在我们的表现层是依赖于逻辑层的，因此我们想到要在中间搭一层接口。这就要用到创建型模式。

表现层可以用工厂模式创建ISplitter的实例，这里我们直接使用反射来创建实例。

这样表现层就不与业务逻辑层直接产生依赖了。

然后我们考虑进度条，这涉及到对象与对象的通知关系，即观察者模式。C#的委托事件机制其实就是这个模式的运用。

在ISplit接口里添加SplitProgressEventHandler委托事件。之所以添加在接口里是因为接口十分稳定。

Split分割文件的实现方法中添加触发进度条事件。

表现层，根据接收到的通知，更新进度条。

然后我们再解决内存暴涨的问题，我们不要一口气读太多的文件内容，我们可以一次读1M，读到规定数量后才写到一个小文件中。另外，我们还可以使用多线程并行地去读一个大文件，这都是属于算法的更改，因此我们可以想到把Split方法划分出去，用Strategy模式解耦。

另外我们还需要写一个文件合并器，这些都可能用到其他的很多设计模式。例如我们还可能需要支持网络上文件的分割，断点续传技术等等，这些都是可能的变化点，需要我们考虑。

 

设计模式应用总结

设计模式建立在对系统变化点的基础上进行，哪里有变化点，哪里应用设计模式。

设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能准确定位。

不能为了模式而模式，设计模式是一种软件设计的软力量，而非规范标准。不应夸大设计模式的作用。

2010.11.1