设计模式之总结与回顾

设计模式之总结与回顾(1)

2013-05-27 12:59 李胜攀博客园我要评论(0)字号：T | T

就Java语言体系来说，GOF是Java基础知识和J2EE框架知识之间一座隐性的"桥"。GoF表面上好像也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好像和J2EE，.Net等技术也无关！

AD：2013大数据全球技术峰会课程PPT下载

从2005年初听说设计模式，到现在虽然已经8年多了，但GoF的23种模式依然盛行，当然GoF 提出这些模式的年代更加久远（1995年）。

在工作的过程中，陆陆续续接触了GoF的大部分模式，我记得在2008年的时候就想总结一下设计模式（最近想做的两件事情），最后因为各种原因也没有完成。最近这段时间正好是职业空档期，没什么事儿做，就把之前看过的设计模式翻出来整理了一下，于是就有了上面几篇文章。

整理设计模式的过程，也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾，让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”，特别是S.O.L.I.D，我觉得在这里再说一次，也不算矫情。

S：单一职责原则（Single Responsibility Principle, SRP），一个类只能有一个原因使其发生改变，即一个类只承担一个职责。

O：开放-封闭原则（Open-Close Principle, OCP），这里指我们的设计应该针对扩展开放，针对修改关闭，即尽量以扩展的方式来维护系统。

L：里氏替换原则（Liskov Subsititution Principle, LSP），它表示我们可以在代码中使用任意子类来替代父类并且程序不受影响，这样可以保证我们使用“继承”并没有破坏父类。

I：接口隔离原则（Interface Segregation Principle, ISP），客户端不应该依赖于它不需要的接口，两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法，而不是大量没用的方法。

D：依赖倒置原则（Dependence Inversion Principle, DIP），高层模块不应该依赖于低层模块，两者应该都依赖于抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主要是提倡“面向接口”编程，而非“面向实现”编程。

设计模式，从本质上讲，是针对过去某种经验的总结。每种设计模式，都是为了在特定条件下去解决特定问题，离开这些前提去讨论设计模式，是没有意义的。

下面，我们快速回顾GoF的23种模式。

∙工厂方法

意图：定义一个用户创建对象的接口，让子类去决定具体使用哪个类。

适用场合：1）类不知道它所要创建的对象的类信息；2）类希望由它的子类来创建对象。

∙抽象工厂

意图：提供一个创建一系列相关或者相互依赖的对象的接口，而无须指定它的具体实现类。

适用场合：1）系统不依赖于产品是如何实现的细节；2）系统的产品族大于1，而在运

行时刻只需要某一种产品族；3）属于同一个产品族的产品，必须绑在一起使用；4）所有的产品族，可以抽取公共接口

∙单例

意图：保证一个类只有一个实例，并且在系统全局范围内提供访问切入点。

适用场合：各种“工厂类”

∙构造者

意图：将复杂对象的构造与表示相分离，使得同样的构造过程可以产生不同的复杂对象。

适用场合：1）需要创建的对象有复杂的内部结构；2）对象的属性之间相互依赖，创建时前后顺序需要指定。

∙原型

意图：用原型实例指定创建对象的种类，并通过复制原型实例得到对象。

适用场合：1）系统不关心对象创建的细节；2）要实例化的对象的类型是动态加载的；

3）类在运行过程中的状态是有限的。

∙适配器

意图：将一个类的接口转换成用户希望的另一个接口。

适用场合：系统需要使用现有类的功能，但接口不匹配

∙装饰

意图：动态的为对象添加额外职责

适用场合：1）需要添加对象职责；2）这些职责可以动态添加或者取消；3）添加的职责很多，从而不能用继承实现。

∙桥接器

意图：将抽象部分与实现部分分离，从而使得它们可以独立变化

适用场合：1）系统需要在组件的抽象化角色与具体化角色之间增加更多的灵活；2）角色的任何变化都不应该影响客户端；3）组件有多个抽象化角色和具体化角色

∙享元

意图：运用共享技术支持大量细粒度的对象

适用场合：1）系统中有大量对象；2）这些对象占据大量内存；3）对象中的状态可以很好的区分为外部和内部；4）可以按照内部状态将对象分为不同的组；5）对系统来讲，同一个组内的对象是不可分辨的

∙门面

意图：为系统的一组接口提供一个一致的界面

适用场合：1）为一个复杂的接口提供一个简单界面；2）保持不同子系统的独立性；3）在分层设计中，定义每一层的入口

∙合成

意图：将对象组装成树状结构以表示“部分-整体”的关系

适用场合：1）系统中的对象之间是“部分-整体”的关系；2）用户不关心“部分”与“整体”之间的区别

∙代理

意图：为其他对象提供一种代理以控制对该对象的访问

适用场合：对象无法直接访问（远程代理）

∙职责链

意图：对目标对象实施一系列的操作，并且不希望调用双方和操作之间有耦合关系

适用场合：1）输入对象需要经过一系列处理；2）这些处理需要在运行时指定；3）需要向多个操作发送处理请求；4）这些处理的顺序是可变的

∙命令

意图：对一类对象公共操作的抽象

适用场合：1）调用者同时和多个执行对象交互；2）需要控制调用本身的生命周期；3）调用可以取消

∙观察者

意图：定义对象之间一种“一对多”的关系，当一个对象发生改变时，所有和它有依赖关系的对象都会得到通知

适用场合：1）抽象模型有两部分，其中一部分依赖于另一部分；2）一个对象的改变会导致其他很多对象发生改变；3）对象之间是松耦合

∙访问者

意图：对一组不同类型的元素进行处理

适用场合：1）一个类型需要依赖于多个不同接口的类型；2）需要经常为一个结构相对稳定的对象添加新操作；3）需要用一个独立的类型来组织一批不相干的操作，使用它的类型可以根据应用需要进行定制

∙模板

意图：定义一个操作步骤的方法骨架，而将其中一些细节的实现放到子类中

适用场合：1）可以抽取方法骨架；2）控制子类的行为，只需要实现特定细节

∙策略

意图：对算法族进行封装

适用场合：1）完成某项业务有多个算法；2）算法可提取公共接口

∙解释器

意图：应用或对象与用户狡猾时，采取最具实效性的方式完成

适用场合：1）针对对象的操作有规律可循；2）在执行过程中，对效率要求不高，但对灵活性要求很高

∙迭代

意图：提供一种方法，来顺序访问集合中的所有元素