第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模式注重封装对象操作变化,支持在运行时为类层次结构动态添加新的操作

 

模式之间的关系图

image

 

例说模式综合应用

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

image

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

浏览

image

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

image

image

image

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

假如现在提出几个需求:

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

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

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

image

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

 

开始重构

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

image

image

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

image

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

 

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

image

image

image

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

image

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

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

image

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

image

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

image

image

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

image

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

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

 

设计模式应用总结

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

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

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

2010.11.1

posted @ 2010-11-01 22:01  山天大畜  阅读(1443)  评论(0编辑  收藏  举报