23 种设计模式汇集
如果你还不了解设计模式是什么的话？
那就先看设计模式引 言 !
学习 GoF 设计模式的重要性
建筑和软件中模式之异同
A. 创建模式
设计模式之 Singleton(单态/单件) 阎宏博士讲解：单例（Singleton）模式
保证一个类只有一个实例,并提供一个访问它的全局访问点
设计模式之 Factory(工厂方法和抽象工厂)
使用工厂模式就象使用 new 一样频繁.
设计模式之 Builder
汽车由车轮 方向盘 发动机很多部件组成，同时，将这些部件组装成汽车也是一件复杂的工作，Builder 模式就是将这两
种情况分开进行。
设计模式之 Prototype(原型)
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
B. 结构模式
设计模式之 Adapter(适配器)
使用类再生的两个方式:组合(new)和继承(extends),这个已经在 thinking in java 中提到过.
设计模式之 Proxy(代理)
以 Jive 为例,剖析代理模式在用户级别授权机制上的应用
设计模式之 Facade(门面？)
可扩展的使用 JDBC 针对不同的数据库编程,Facade 提供了一种灵活的实现.
设计模式之 Composite(组合)
就是将类用树形结构组合成一个单位.你向别人介绍你是某单位，你是单位中的一个元素，别人和你做买卖，相当于
和单位做买卖。文章中还对 Jive 再进行了剖析。
设计模式之 Decorator(装饰器)
Decorator 是个油漆工,给你的东东的外表刷上美丽的颜色.
设计模式之 Bridge(桥连)
将牛郎织女分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合)
设计模式之 Flyweight(共享元)
提供 Java 运行性能,降低小而大量重复的类的开销.
C. 行为模式
设计模式之 Command(命令)
什么是将行为封装,Command 是最好的说明.
设计模式之 Observer(观察者)
介绍如何使用 Java API 提供的现成 Observer
设计模式之 Iterator(迭代器)
这个模式已经被整合入 Java 的 Collection.在大多数场合下无需自己制造一个 Iterator,只要将对象装入 Collection 中，
直接使用 Iterator 进行对象遍历。
设计模式之 Template(模板方法)
实际上向你介绍了为什么要使用 Java 抽象类,该模式原理简单,使用很普遍.
设计模式之 Strategy(策略)
不同算法各自封装,用户端可随意挑选需要的算法.
设计模式之 Chain of Responsibility(责任链)
各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个.
设计模式之 Mediator(中介)
Mediator 很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以.
设计模式之 State(状态)
状态是编程中经常碰到的实例,将状态对象化,设立状态变换器,便可在状态中轻松切换.
设计模式之 Memento(注释状态？)
很简单一个模式,就是在内存中保留原来数据的拷贝.
设计模式之 Interpreter(解释器)
主要用来对语言的分析,应用机会不多.
设计模式之 Visitor(访问者)
访问者在进行访问时,完成一系列实质性操作,而且还可以扩展.
设计模式引言
设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。你必须找到相关的对象，以适当的粒度将它们归
类，再定义类的接口和继承层次，建立对象之间的基本关系。你的设计应该对手头的问题有针对性，同时对将来的问题和需求
也要有足够的通用性。
你也希望避免重复设计或尽可能少做重复设计。有经验的面向对象设计者会告诉你，要一下子就得到复用性和灵活性好的设计，
即使不是不可能的至少也是非常困难的。一个设计在最终完成之前常要被复用好几次，而且每一次都有所修改。
有经验的面向对象设计者的确能做出良好的设计，而新手则面对众多选择无从下手，总是求助于以前使用过的非面向对象
技术。新手需要花费较长时间领会良好的面向对象设计是怎么回事。有经验的设计者显然知道一些新手所不知道的东西，这又
是什么呢？
内行的设计者知道：不是解决任何问题都要从头做起。他们更愿意复用以前使用过的解决方案。当找到一个好的解决方案，他
们会一遍又一遍地使用。这些经验是他们成为内行的部分原因。因此，你会在许多面向对象系统中看到类和相互通信的对象（ c
o m m u n i c a t i n go b j e c t）的重复模式。这些模式解决特定的设计问题，使面向对象设计更灵活、优雅，最终复用性更
好。它们帮助设计者将新的设计建立在以往工作的基础上，复用以往成功的设计方案。
一个熟悉这些模式的设计者不需要再去发现它们，而能够立即将它们应用于设计问题中。以下类比可以帮助说明这一点。
小说家和剧本作家很少从头开始设计剧情。他们总是沿袭一些业已存在的模式，像“悲剧性英雄”模式(《麦克白》、《哈姆雷特》
等)或“浪漫小说”模式(存在着无数浪漫小说)。同样地，面向对象设计员也沿袭一些模式，像“用对象表示状态”和“修饰对象以便
于你能容易地添加/删除属性”等。一旦懂得了模式，许多设计决策自然而然就产生了。
我们都知道设计经验的重要价值。你曾经多少次有过这种感觉—你已经解决过了一个问题但就是不能确切知道是在什么地
方或怎么解决的？如果你能记起以前问题的细节和怎么解决它的，你就可以复用以前的经验而不需要重新发现它。然而，我们
并没有很好记录下可供他人使用的软件设计经验。
学习 GoF 设计模式的重要性
著名的 EJB 领域顶尖的专家 Richard Monson-Haefel 在其个人网站:www.EJBNow.com 中极力推荐的 GoF 的《设计模式》,原文
如下:
Design Patterns
Most developers claim to experience an epiphany reading this book. If you've never read the Design Patterns book then you have
suffered a very serious gap in your programming education that should be remedied immediately.
翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读
过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补!
可以这么说：GoF 设计模式是程序员真正掌握面向对象核心思想的必修课。虽然你可能已经通过了 SUN 的很多令人炫目的
技术认证，但是如果你没有学习掌握 GoF 设计模式，只能说明你还是一个技工。
在浏览《Thingking in Java》(第一版)时，你是不是觉得好象这还是一本 Java 基础语言书籍？但又不纯粹是，因为这本书的作
者将面向对象的思想巧妙的融合在 Java 的具体技术上，潜移默化的让你感觉到了一种新的语言和新的思想方式的诞生。
但是读完这本书，你对书中这些蕴含的思想也许需要一种更明晰更系统更透彻的了解和掌握，那么你就需要研读 GoF 的《设
计模式》了。
《Thingking in Java》(第一版中文)是这样描述设计模式的：他在由 Gamma, Helm 和 Johnson Vlissides 简称 Gang of Four(四人
帮),缩写 GoF 编著的《Design Patterns》一书中被定义成一个“里程碑”。事实上，那本书现在已成为几乎所有 OOP(面向对象程
序设计)程序员都必备的参考书。(在国外是如此)。
GoF 的《设计模式》是所有面向对象语言(C++ Java C#)的基础，只不过不同的语言将之实现得更方便地使用。
GOF 的设计模式是一座"桥"
就 Java 语言体系来说，GOF 的设计模式是 Java 基础知识和 J2EE 框架知识之间一座隐性的"桥"。
会 Java 的人越来越多，但是一直徘徊在语言层次的程序员不在少数，真正掌握 Java 中接口或抽象类的应用不是很多，大家
经常以那些技术只适合大型项目为由，避开或忽略它们，实际中，Java 的接口或抽象类是真正体现 Java 思想的核心所在，这些
你都将在 GoF 的设计模式里领略到它们变幻无穷的魔力。
GoF 的设计模式表面上好象也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这
些好象和 J2EE .Net 等技术也无关！
实际上，GoF 的设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用
和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的 Java 语言基础上跃进一步，更重要的是，GoF 的设计模式反复
向你强调一个宗旨：要让你的程序尽可能的可重用。
这其实在向一个极限挑战：软件需求变幻无穷，计划没有变化快，但是我们还是要寻找出不变的东西，并将它和变化的东
西分离开来，这需要非常的智慧和经验。
而 GoF 的设计模式是在这方面开始探索的一块里程碑。
J2EE 等属于一种框架软件，什么是框架软件？它不同于我们以前接触的 Java API 等，那些属于 Toolkist(工具箱)，它不再被动
的被使用，被调用，而是深刻的介入到一个领域中去，J2EE 等框架软件设计的目的是将一个领域中不变的东西先定义好，比如
整体结构和一些主要职责(如数据库操作 事务跟踪 安全等)，剩余的就是变化的东西，针对这个领域中具体应用产生的具体不同
的变化需求，而这些变化东西就是 J2EE 程序员所要做的。
由此可见，设计模式和 J2EE 在思想和动机上是一脉相承，只不过
1.设计模式更抽象，J2EE 是具体的产品代码，我们可以接触到，而设计模式在对每个应用时才会产生具体代码。
2.设计模式是比 J2EE 等框架软件更小的体系结构，J2EE 中许多具体程序都是应用设计模式来完成的，当你深入到 J2EE 的内
部代码研究时，这点尤其明显，因此，如果你不具备设计模式的基础知识(GoF 的设计模式)，你很难快速的理解 J2EE。不能理解
J2EE,如何能灵活应用？
3.J2EE 只是适合企业计算应用的框架软件，但是 GoF 的设计模式几乎可以用于任何应用！因此 GoF 的设计模式应该是 J2EE
的重要理论基础之一。
所以说，GoF 的设计模式是 Java 基础知识和 J2EE 框架知识之间一座隐性的"桥"。为什么说隐性的？
GOF 的设计模式是一座隐性的"桥"
因为很多人没有注意到这点，学完 Java 基础语言就直接去学 J2EE,有的甚至鸭子赶架，直接使用起 Weblogic 等具体 J2EE 软
件，一段时间下来，发现不过如此，挺简单好用，但是你真正理解 J2EE 了吗？你在具体案例中的应用是否也是在延伸 J2EE 的思
想？
如果你不能很好的延伸 J2EE 的思想，那你岂非是大炮轰蚊子，认识到 J2EE 不是适合所有场合的人至少是明智的，但我们更
需要将 J2EE 用对地方，那么只有理解 J2EE 此类框架软件的精髓，那么你才能真正灵活应用 Java 解决你的问题，甚至构架出你自
己企业的框架来。(我们不能总是使用别人设定好的框架，为什么不能有我们自己的框架？)
因此，首先你必须掌握 GoF 的设计模式。虽然它是隐性，但不是可以越过的。
关于本站“设计模式”
Java 提供了丰富的 API，同时又有强大的数据库系统作底层支持，那么我们的编程似乎变成了类似积木的简单"拼凑"和调用，
甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至.
在真正可复用的面向对象编程中,GoF 的《设计模式》为我们提供了一套可复用的面向对象技术,再配合 Refactoring(重构方法),
所以很少存在简单重复的工作,加上 Java 代码的精炼性和面向对象纯洁性(设计模式是 java 的灵魂),编程工作将变成一个让你时刻
体验创造快感的激动人心的过程.
为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解 GoF 的《设计模式》。由
于原著都是以 C++为例, 以 Java 为例的设计模式基本又都以图形应用为例,而我们更关心 Java 在中间件等服务器方面的应用,因此,
本站所有实例都是非图形应用,并且顺带剖析 Jive 论坛系统.同时为降低理解难度，尽量避免使用 UML 图.
如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就
培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀
程序员的必备条件.
整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性.
建筑和软件中模式之异同
CSDN 的透明特别推崇《建筑的永恒之道》,认为从中探寻到软件的永恒之道,并就"设计模式"写了专门文章《探寻软件的永恒
之道 》,其中很多观点我看了很受启发,以前我也将"设计模式" 看成一个简单的解决方案,没有从一种高度来看待"设计模式"在软
件中地位,下面是我自己的一些想法:
建筑和软件某些地方是可以来比喻的
特别是中国传统建筑,那是很讲模式的,这些都是传统文化使然,比如京剧 一招一式都有套路;中国画,也有套路,树应该怎么画
法?有几种画法?艺术大家通常是创造出自己的套路,比如明末清初,水墨画法开始成熟,这时画树就不用勾勒这个模式了,而是一笔
下去,浓淡几个叶子,待毛笔的水墨要干枯时,画一下树干,这样,一个活生写意的树就画出来.
我上面这些描述其实都是一种模式,创建模式的人是大师,但是拘泥于模式的人永远是工匠.
再回到传统建筑中,中国的传统建筑是过分注重模式了,所以建筑风格发展不大,基本分南北两派,大家有个感觉,旅游时,到南
方,你发现古代名居建筑都差不多;北方由于受满人等少数民族的影响,在建筑色彩上有些与南方迥异,但是很多细节地方都差不多.
这些都是模式的体现.
由于建筑受材料和功用以及费用的影响,所用模式种类不多,这点是和软件很大的不同.
正因为这点不同,导致建筑的管理模式和软件的管理模式就有很多不同, 有些人认识不到这点,就产生了可以大量使用"软件
蓝领"的想法,因为他羡慕建筑中"民工"的低成本.
要知道软件还有一个与建筑截然相反的责任和用途,那就是:现代社会中,计划感不上变化,竞争激烈,所有一切变幻莫测,要应
付所有这些变化,首推信息技术中的软件,只有软件能够帮助人类去应付各种变化.而这点正好与建筑想反,建筑是不能帮助人类去
应付变化的,(它自己反而要求稳固,老老实实帮助人遮风避雨,总不能叫人类在露天或树叶下打开电脑编软件吧).
软件要帮助人类去应付变化,这是软件的首要责任,所以,软件中模式产生的目的就和建筑不一样了,建筑中的模式产生可以因
为很多原因:建筑大师的创意;材料的革新等;建筑中这些模式一旦产生,容易发生另外一个缺点,就是有时会阻碍建筑本身的发展,
因为很多人会不思创造,反复使用老的模式进行设计,阻碍建筑的发展.
但是在软件中,这点正好相反,软件模式的产生是因为变化的东西太多,为减轻人类的负担,将一些不变的东西先用模式固化,这
样让人类可以更加集中精力对付变化的东西,所以在软件中大量反复使用模式(我个人认为这样的软件就叫框架软件了,比如 J2EE),
不但没阻碍软件的发展,反而是推动了软件的发展.因为其他使用这套软件的人就可以将更多精力集中在对付那些无法用模式的
应用上来.
可以关于建筑和软件中的模式作用可以总结如下:
在软件中,模式是帮助人类向"变化"战斗,但是在软件中还需要和'变化'直接面对面战斗的武器:人的思维,特别是创造 分析思
维等等，这些是软件真正的灵魂，这种思维可以说只要有实践需求(如有新项目)就要求发生，发生频度高，人类的创造或分析思
维决定了软件的质量和特点。
而在建筑中,模式可以构成建筑全部知识，当有新的需求(如有新项目)，一般使用旧的模式都可以完成，因此对人类的创造以
及分析思维不是每个项目都必须的，也不是非常重要的，对创造性的思维的需求只是属于锦上添花（除非人类以后离开地球居
住了〕。
设计模式之 Singleton(单态)
模式实战书籍《Java 实用系统开发指南》
单态定义:
Singleton 模式主要作用是保证在 Java 应用程序中，一个类 Class 只有一个实例存在。
在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。
还有, singleton 能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的
帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能 synchronize 的安全自动加 1，如果你要把这个数字
永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。
另外方面，Singleton 也能够被无状态化。提供工具性质的功能，
Singleton 模式就为我们提供了这样实现的可能。使用 Singleton 的好处还在于可以节省内存，因为它限制了实例的个数，有
利于 Java 垃圾回收（garbage collection）。
我们常常看到工厂模式中类装入器(class loader)中也用 Singleton 模式实现的,因为被装入的类实际也属于资源。
如何使用?
一般 Singleton 模式通常有几种形式:
public class Singleton {
private Singleton(){}
//在自己内部定义自己一个实例，是不是很奇怪？
//注意这是 private 只供内部调用
private static Singleton instance = new Singleton();
//这里提供了一个供外部访问本 class 的静态方法，可以直接访问
public static Singleton getInstance() {
return instance;
}
}
第二种形式:
public class Singleton {
private static Singleton instance = null;
public static synchronized Singleton getInstance() {
//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次
//使用时生成实例，提高了效率！
if (instance==null)
instance＝new Singleton();
return instance; }
}
使用 Singleton.getInstance()可以访问单态类。
上面第二中形式是 lazy initialization，也就是说第一次调用时初始 Singleton，以后就不用再生成了。
注意到 lazy initialization 形式中的 synchronized，这个 synchronized 很重要，如果没有 synchronized，那么使用 getInstance()
是有可能得到多个 Singleton 实例。关于 lazy initialization 的 Singleton 有很多涉及 double-checked locking (DCL)的讨论，有兴趣者
进一步研究。
一般认为第一种形式要更加安全些。
使用 Singleton 注意事项：
有时在某些情况下，使用 Singleton 并不能达到 Singleton 的目的，如有多个 Singleton 对象同时被不同的类装入器装载；在
EJB 这样的分布式系统中使用也要注意这种情况，因为 EJB 是跨服务器，跨 JVM 的。
我们以 SUN 公司的宠物店源码(Pet Store 1.3.1)的 ServiceLocator 为例稍微分析一下：
