java中23种设计模式详细

23种设计模式汇集

如果你还不了解设计模式是什么的话？

那就先看设计模式引言 !

学习GoF

设计模式的重要性

建筑和软件中模式之异同

A. 创建模式

设计模式之Singleton(单态/单件) 阎宏博士讲解：单例（Singleton）模式

保证一个类只有一个实例,并提供一个访问它的全局访问点

设计模式之Factory(工厂方法和抽象工厂)

使用工厂模式就象使用new一样频繁.

汽车由车轮 方向盘 发动机很多部件组成，同时，将这些部件组装成汽车也是一件复杂的工作，Builder模式就是将这两种情况分开进行。

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

B. 结构模式

设计模式之Adapter(适配器)

使用类再生的两个方式:组合(new)和继承(extends),这个已经在thinking in java中提到过.

设计模式之Proxy(代理)

以Jive为例,剖析代理模式在用户级别授权机制上的应用

设计模式之Facade(门面？)

可扩展的使用JDBC针对不同的数据库编程,Facade提供了一种灵活的实现.

就是将类用树形结构组合成一个单位.你向别人介绍你是某单位，你是单位中的一个元素，别人和你做买卖，相当于和单位做买卖。文章中还对Jive再进行了剖析。

设计模式之Decorator(装饰器)

Decorator是个油漆工,给你的东东的外表刷上美丽的颜色.

设计模式之Bridge(桥连)

将牛郎织女分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合)

提供Java运行性能,降低小而大量重复的类的开销.

C. 行为模式

设计模式之Command(命令)

什么是将行为封装,Command是最好的说明.

设计模式之Observer(观察者)

介绍如何使用Java API提供的现成Observer

设计模式之Iterator(迭代器)

这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中，直接使用Iterator进行对象遍历。

设计模式之Template(模板方法)

java中23种设计模式详细

实际上向你介绍了为什么要使用Java 抽象类,该模式原理简单,使用很普遍.

设计模式之Strategy(策略)

不同算法各自封装,用户端可随意挑选需要的算法.

设计模式之Chain of Responsibility(责任链)

各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个.

Mediator很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以.

状态是编程中经常碰到的实例,将状态对象化,设立状态变换器,便可在状态中轻松切换.

设计模式之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在其个人网站:http://中极力推荐的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.

翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补!

java中23种设计模式详细

可以这么说：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中23种设计模式详细

Java提供了丰富的API，同时又有强大的数据库系统作底层支持，那么我们的编程似乎变成了类似积木的简单"拼凑"和调用，甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至.

在真正可复用的面向对象编程中,GoF的《设计模式》为我们提供了一套可复用的面向对象技术,再配合Refactoring(重构方法),所以很少存在简单重复的工作,加上Java代码的精炼性和面向对象纯洁性(设计模式是java的灵魂),编程工作将变成一个让你时刻体验创造快感的激动人心的过程.

为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解GoF的《设计模式》。由于原著都是以C++为例, 以Java为例的设计模式基本又都以图形应用为例,而我们更关心Java在中间件等服务器方面的应用,因此,本站所有实例都是非图形应用,并且顺带剖析Jive论坛系统.同时为降低理解难度，尽量避免使用UML图.

如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序员的必备条件.

整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性.

建筑和软件中模式之异同

CSDN的透明特别推崇《建筑的永恒之道》,认为从中探寻到软件的永恒之道,并就"设计模式"写了专门文章《探寻软件的永恒之道 》,其中很多观点我看了很受启发,以前我也将"设计模式" 看成一个简单的解决方案,没有从一种高度来看待"设计模式"在软件中地位,下面是我自己的一些想法:

建筑和软件某些地方是可以来比喻的

特别是中国传统建筑,那是很讲模式的,这些都是传统文化使然,比如京剧 一招一式都有套路;中国画,也有套路,树应该怎么画法?有几种画法?艺术大家通常是创造出自己的套路,比如明末清初,水墨画法开始成熟,这时画树就不用勾勒这个模式了,而是一笔下去,浓淡几个叶子,待毛笔的水墨要干枯时,画一下树干,这样,一个活生写意的树就画出来.

我上面这些描述其实都是一种模式,创建模式的人是大师,但是拘泥于模式的人永远是工匠.

再回到传统建筑中,中国的传统建筑是过分注重模式了,所以建筑风格发展不大,基本分南北两派,大家有个感觉,旅游时,到南方,你发现古代名居建筑都差不多;北方由于受满人等少数民族的影响,在建筑色彩上有些与南方迥异,但是很多细节地方都差不多.这些都是模式的体现.

由于建筑受材料和功用以及费用的影响,所用模式种类不多,这点是和软件很大的不同.

正因为这点不同,导致建筑的管理模式和软件的管理模式就有很多不同, 有些人认识不到这点,就产生了可以大量使用"软件蓝领"的想法,因为他羡慕建筑中"民工"的低成本.

要知道软件还有一个与建筑截然相反的责任和用途,那就是:现代社会中,计划感不上变化,竞争激烈,所有一切变幻莫测,要应付所有这些变化,首推信息技术中的软件,只有软件能够帮助人类去应付各种变化.而这点正好与建筑想反,建筑是不能帮助人类去应付变化的,(它自己反而要求稳固,老老实实帮助人遮风避雨,总不能叫人类在露天或树叶下打开电脑编软件吧).

软件要帮助人类去应付变化,这是软件的首要责任,所以,软件中模式产生的目的就和建筑不一样了,建筑中的模式产生可以因为很多原因:建筑大师的创意;材料的革新等;建筑中这些模式一旦产生,容易发生另外一个缺点,就是有时会阻碍建筑本身的发展,因为很多人会不思创造,反复使用老的模式进行设计,阻碍建筑的发展.

但是在软件中,这点正好相反,软件模式的产生是因为变化的东西太多,为减轻人类的负担,将一些不变的东西先用模式固化,这样让人类可以更加集中精力对付变化的东西,所以在软件中大量反复使用模式(我个人认为这样的软件就叫框架软件了,比如J2EE),不但没阻碍软件的发展,反而是推动了软件的发展.因为其他使用这套软件的人就可以将更多精力集中在对付那些无法用模式的应用上来.

可以关于建筑和软件中的模式作用可以总结如下:

在软件中,模式是帮助人类向"变化"战斗,但是在软件中还需要和'变化'直接面对面战斗的武器:人的思维,特别是创造 分析思维等等，这些是软件真正的灵魂，这种思维可以说只要有实践需求(如有新项目)就要求发生，发生频度高，人类的创造或分析思维决定了软件的质量和特点。

而在建筑中,模式可以构成建筑全部知识，当有新的需求(如有新项目)，一般使用旧的模式都可以完成，因此对人类的创造以及分析思维不是每个项目都必须的，也不是非常重要的，对创造性的思维的需求只是属于锦上添花（除非人类以后离开地球居住了〕。

java中23种设计模式详细

设计模式之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为例稍微分析一下：

java中23种设计模式详细

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。

总之：如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术。

进一步深入可参考：

Double-checked locking and the Singleton pattern

When is a singleton not a singleton?

设计模式如何在具体项目中应用见《Java实用系统开发指南》。

设计模式之Factory

工厂模式定义:提供创建对象的接口.

为何使用?

工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。 为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。

我们以类Sample为例， 如果我们要创建Sample的实例对象:

Sample sample=new Sample();

可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成:

Sample sample=new Sample(参数);

但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重整）。

为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于Java面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。

在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample .我们要实例化他们时,如下:

Sample mysample=new MySample();

Sample hissample=new HisSample();

随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.

但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.

工厂方法

你会建立一个专门生产Sample实例的工厂: public class Factory{

public static Sample creator(int which){

//getClass 产生Sample 一般可使用动态类装载装入类。

java中23种设计模式详细

if (which==1)

return new SampleA();

else if (which==2)

return new SampleB();

}

}

那么在你的程序中,如果要实例化Sample时.就使用

Sample sampleA=Factory.creator(1);

这样,在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻:就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可能性就越少.好象我们从编程序中也能悟出人生道理?呵呵.

使用工厂方法 要注意几个角色，首先你要定义产品接口，如上面的Sample,产品接口下有Sample接口的实现类,如SampleA,其次要有一个factory类，用来生成产品Sample，如下图，最右边是生产的对象Sample：

进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类concreteFactory了。

抽象工厂

工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory).

这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.

这里假设：Sample有两个concrete类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和SampleB2

那么，我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂: public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);

}

public class SimpleFactory extends Factory{

public Sample creator(){

.........

return new SampleA

}

public Sample2 creator(String name){

.........

return new Sample2A

}

java中23种设计模式详细

}

public class BombFactory extends Factory{

public Sample creator(){

......

return new SampleB

}

public Sample2 creator(String name){

......

return new Sample2B

}

}

从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2?

抽象工厂还有另外一个关键要点，是因为 SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如：制造工艺比较简单，所以名称叫SimpleFactory。

在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用，

举例

我们以Jive的ForumFactory为例，这个例子在前面的Singleton模式中我们讨论过，现在再讨论其工厂模式: public abstract class ForumFactory {

private static Object initLock = new Object();

private static String className = "com.jivesoftware.forum.database.DbForumFactory";

private static ForumFactory factory = null;

public static ForumFactory getInstance(Authorization authorization) {

//If no valid authorization passed in, return null.

if (authorization == null) {

return null;

}

//以下使用了Singleton 单态模式

if (factory == null) {

synchronized(initLock) {

if (factory == null) {

......

try {

//动态转载类

Class c = Class.forName(className);

factory = (ForumFactory)c.newInstance();

}

catch (Exception e) {

return null;

}

}

}

java中23种设计模式详细

}

//Now, 返回 proxy.用来限制授权对forum的访问

return new ForumFactoryProxy(authorization, factory,

factory.getPermissions(authorization));

}

//真正创建forum的方法由继承forumfactory的子类去完成.

public abstract Forum createForum(String name, String description)

throws UnauthorizedException, ForumAlreadyExistsException;

....

}

因为现在的Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法

ForumFactory就提供了提供动态接口:

private static String className = "com.jivesoftware.forum.database.DbForumFactory";

你可以使用自己开发的创建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.

在上面的一段代码中一共用了三种模式,除了工厂模式外,还有Singleton单态模式,以及proxy模式,proxy模式主要用来授权用户对forum的访问,因为访问forum有两种人:一个是注册用户 一个是游客guest,那么那么相应的权限就不一样,而且这个权限是贯穿整个系统的,因此建立一个proxy,类似网关的概念,可以很好的达到这个效果.

看看Java宠物店中的CatalogDAOFactory: public class CatalogDAOFactory {

/**

* 本方法制定一个特别的子类来实现DAO模式。

* 具体子类定义是在J2EE的部署描述器中。

*/

public static CatalogDAO getDAO() throws CatalogDAOSysException {

CatalogDAO catDao = null;

try {

InitialContext ic = new InitialContext();

//动态装入CATALOG_DAO_CLASS

//可以定义自己的CATALOG_DAO_CLASS，从而在无需变更太多代码

//的前提下，完成系统的巨大变更。

String className =(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);

catDao = (CatalogDAO) Class.forName(className).newInstance();

} catch (NamingException ne) {

throw new CatalogDAOSysException("

CatalogDAOFactory.getDAO: NamingException while

getting DAO type : \n" + ne.getMessage());

} catch (Exception se) {

throw new CatalogDAOSysException("

CatalogDAOFactory.getDAO: Exception while getting

DAO type : \n" + se.getMessage());

}

return catDao;

}

}

java中23种设计模式详细

CatalogDAOFactory是典型的工厂方法，catDao是通过动态类装入器className获得CatalogDAOFactory具体实现子类，这个实现子类在Java宠物店是用来操作catalog数据库，用户可以根据数据库的类型不同，定制自己的具体实现子类，将自己的子类名给与CATALOG_DAO_CLASS变量就可以。

由此可见，工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制，只要我们更换一下具体的工厂方法，系统其他地方无需一点变换，就有可能将系统功能进行改头换面的变化。

设计模式之Builder

Builder模式定义:

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.

Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到.

为何使用?

是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件.

因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.

如何使用?

首先假设一个复杂对象是由多个部件组成的,Builder模式是把复杂对象的创建和部件的创建分别开来,分别用Builder类和Director类来表示.

首先,需要一个接口,它定义如何创建复杂对象的各个部件:

public interface Builder {

//创建部件A 比如创建汽车车轮

void buildPartA();

//创建部件B 比如创建汽车方向盘

void buildPartB();

//创建部件C 比如创建汽车发动机

void buildPartC();

//返回最后组装成品结果 (返回最后装配好的汽车)

//成品的组装过程不在这里进行,而是转移到下面的Director类中进行.

//从而实现了解耦过程和部件

Product getResult();

}

用Director构建最后的复杂对象,而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就是说Director的内容是如何将部件最后组装成成品:

public class Director {

private Builder builder;

public Director( Builder builder ) {

this.builder = builder;

}

// 将部件partA partB partC最后组成复杂对象

//这里是将车轮 方向盘和发动机组装成汽车的过程

public void construct() {

builder.buildPartA();

builder.buildPartB();

builder.buildPartC();

java中23种设计模式详细

}

}

Builder的具体实现ConcreteBuilder:

通过具体完成接口Builder来构建或装配产品的部件;

定义并明确它所要创建的是什么具体东西;

提供一个可以重新获取产品的接口:

public class ConcreteBuilder implements Builder {

Part partA, partB, partC;

public void buildPartA() {

//这里是具体如何构建partA的代码

};

public void buildPartB() {

//这里是具体如何构建partB的代码

};

public void buildPartC() {

//这里是具体如何构建partB的代码

};

public Product getResult() {

//返回最后组装成品结果

};

}

复杂对象:产品Product:

public interface Product { }

复杂对象的部件:

public interface Part { }

我们看看如何调用Builder模式:

ConcreteBuilder builder = new ConcreteBuilder();

Director director = new Director( builder );

director.construct();

Product product = builder.getResult();

Builder模式的应用

在Java实际使用中,我们经常用到"池"(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池.

"池"实际是一段内存,当池中有一些复杂的资源的"断肢"(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这些"断肢",将提高内存使用效率,提高池的性能.修改Builder模式中Director类使之能诊断"断肢"断在哪个部件上,再修复这个部件.

设计模式之Prototype(原型)

原型模式定义:

用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.

Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。

如何使用?

因为Java中的提供clone()方法来实现对象的克隆,所以Prototype模式实现一下子变得很简单.

以勺子为例：

java中23种设计模式详细

public abstract class AbstractSpoon implements Cloneable

{

String spoonName;

public void setSpoonName(String spoonName) {this.spoonName = spoonName;}

public String getSpoonName() {return this.spoonName;}

public Object clone()

{

Object object = null;

try {

object = super.clone();

} catch (CloneNotSupportedException exception) {

System.err.println("AbstractSpoon is not Cloneable");

}

return object;

}

} 有个具体实现(ConcretePrototype):

public class SoupSpoon extends AbstractSpoon

{

public SoupSpoon()

{

setSpoonName("Soup Spoon");

}

}

调用Prototype模式很简单:

AbstractSpoon spoon = new SoupSpoon();

AbstractSpoon spoon2 = spoon.clone();

当然也可以结合工厂模式来创建AbstractSpoon实例。

在Java中Prototype模式变成clone()方法的使用，由于Java的纯洁的面向对象特性，使得在Java中使用设计模式变得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如Interator遍历模式。

设计模式之Adapter(适配器)

适配器模式定义:

将两个不兼容的类纠合在一起使用，属于结构型模式,需要有Adaptee(被适配者)和Adaptor(适配器)两个身份.

为何使用?

我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或者，我们不愿意为了一个应用而修改各自的接口。 怎么办?

使用Adapter，在这两种接口之间创建一个混合接口(混血儿).

如何使用?

实现Adapter方式,其实"think in Java"的"类再生"一节中已经提到,有两种方式：组合(composition)和继承

(inheritance).

假设我们要打桩，有两种类：方形桩 圆形桩.

public class SquarePeg{

public void insert(String str){

java中23种设计模式详细

System.out.println("SquarePeg insert():"+str);

}

}

public class RoundPeg{

public void insertIntohole(String msg){

System.out.println("RoundPeg insertIntoHole():"+msg);

}

}

现在有一个应用,需要既打方形桩,又打圆形桩.那么我们需要将这两个没有关系的类综合应用.假设RoundPeg我们没有源代码,或源代码我们不想修改,那么我们使用Adapter来实现这个应用:

public class PegAdapter extends SquarePeg{

private RoundPeg roundPeg;

public PegAdapter(RoundPeg peg)(this.roundPeg=peg;)

public void insert(String str){ roundPeg.insertIntoHole(str);}

}

在上面代码中,RoundPeg属于Adaptee,是被适配者.PegAdapter是Adapter,将Adaptee(被适配者RoundPeg)和Target(目标SquarePeg)进行适配.实际上这是将组合方法(composition)和继承(inheritance)方法综合运用.

PegAdapter首先继承SquarePeg，然后使用new的组合生成对象方式，生成RoundPeg的对象roundPeg，再重载父类insert()方法。从这里,你也了解使用new生成对象和使用extends继承生成对象的不同,前者无需对原来的类修改,甚至无需要知道其内部结构和源代码.

如果你有些Java使用的经验，已经发现，这种模式经常使用。

进一步使用

上面的PegAdapter是继承了SquarePeg,如果我们需要两边继承，即继承SquarePeg 又继承RoundPeg,因为Java中不允许多继承，但是我们可以实现(implements)两个接口(interface)

public interface IRoundPeg{

public void insertIntoHole(String msg);

}

public interface ISquarePeg{

public void insert(String str);

}

下面是新的RoundPeg 和SquarePeg, 除了实现接口这一区别，和上面的没什么区别。

public class SquarePeg implements ISquarePeg{

public void insert(String str){

System.out.println("SquarePeg insert():"+str);

}

}

public class RoundPeg implements IRoundPeg{

public void insertIntohole(String msg){

System.out.println("RoundPeg insertIntoHole():"+msg);

}

}

下面是新的PegAdapter,叫做two-way adapter:

public class PegAdapter implements IRoundPeg,ISquarePeg{

private RoundPeg roundPeg;

java中23种设计模式详细

private SquarePeg squarePeg;

// 构造方法

public PegAdapter(RoundPeg peg){this.roundPeg=peg;}

// 构造方法

public PegAdapter(SquarePeg peg)(this.squarePeg=peg;)

public void insert(String str){ roundPeg.insertIntoHole(str);}

}

还有一种叫Pluggable Adapters,可以动态的获取几个adapters中一个。使用Reflection技术，可以动态的发现类中的Public方法。

设计模式之Proxy(代理)

理解并使用设计模式,能够培养我们良好的面向对象编程习惯,同时在实际应用中,可以如鱼得水,享受游刃有余的乐趣. 代理模式是比较有用途的一种模式,而且变种较多,应用场合覆盖从小结构到整个系统的大结构,Proxy是代理的意思,我们也许有代理服务器等概念,代理概念可以解释为:在出发点到目的地之间有一道中间层,意为代理.

设计模式中定义: 为其他对象提供一种代理以控制对这个对象的访问.

为什么要使用Proxy?

1.授权机制 不同级别的用户对同一对象拥有不同的访问权利,如Jive论坛系统中,就使用Proxy进行授权机制控制,访问论坛有两种人:注册用户和游客(未注册用户),Jive中就通过类似ForumProxy这样的代理来控制这两种用户对论坛的访问权限.

2.某个客户端不能直接操作到某个对象,但又必须和那个对象有所互动.

举例两个具体情况:

(1)如果那个对象是一个是很大的图片,需要花费很长时间才能显示出来,那么当这个图片包含在文档中时,使用编辑器或浏览器打开这个文档,打开文档必须很迅速,不能等待大图片处理完成,这时需要做个图片Proxy来代替真正的图片.

(2)如果那个对象在Internet的某个远端服务器上,直接操作这个对象因为网络速度原因可能比较慢,那我们可以先用Proxy来代替那个对象.

总之原则是,对于开销很大的对象,只有在使用它时才创建,这个原则可以为我们节省很多宝贵的Java内存. 所以,有些人认为Java耗费资源内存,我以为这和程序编制思路也有一定的关系.

如何使用Proxy?

以Jive论坛系统为例,访问论坛系统的用户有多种类型:注册普通用户 论坛管理者 系统管理者 游客,注册普通用户才能发言;论坛管理者可以管理他被授权的论坛;系统管理者可以管理所有事务等,这些权限划分和管理是使用Proxy完成的. Forum是Jive的核心接口,在Forum中陈列了有关论坛操作的主要行为,如论坛名称 论坛描述的获取和修改,帖子发表删除编辑等.

在ForumPermissions中定义了各种级别权限的用户: public class ForumPermissions implements Cacheable {

/**

* Permission to read object.

*/

public static final int READ = 0;

/**

* Permission to administer the entire sytem.

*/

public static final int SYSTEM_ADMIN = 1;

/**

* Permission to administer a particular forum.

*/

java中23种设计模式详细

public static final int FORUM_ADMIN = 2;

/**

* Permission to administer a particular user.

*/

public static final int USER_ADMIN = 3;

/**

* Permission to administer a particular group.

*/

public static final int GROUP_ADMIN = 4;

/**

* Permission to moderate threads.

*/

public static final int MODERATE_THREADS = 5;

/**

* Permission to create a new thread.

*/

public static final int CREATE_THREAD = 6;

/**

* Permission to create a new message.

*/

public static final int CREATE_MESSAGE = 7;

/**

* Permission to moderate messages.

*/

public static final int MODERATE_MESSAGES = 8; .....

public boolean isSystemOrForumAdmin() {

return (values[FORUM_ADMIN] || values[SYSTEM_ADMIN]);

}

.....

}

因此,Forum中各种操作权限是和ForumPermissions定义的用户级别有关系的,作为接口Forum的实现:ForumProxy正是将这种对应关系联系起来.比如,修改Forum的名称,只有论坛管理者或系统管理者可以修改,代码如下:

public class ForumProxy implements Forum {

private ForumPermissions permissions;

private Forum forum;

this.authorization = authorization;

public ForumProxy(Forum forum, Authorization authorization,

ForumPermissions permissions)

{

this.forum = forum;

this.authorization = authorization;

this.permissions = permissions;

java中23种设计模式详细

}

.....

public void setName(String name) throws UnauthorizedException,

ForumAlreadyExistsException

{

//只有是系统或论坛管理者才可以修改名称

if (permissions.isSystemOrForumAdmin()) {

forum.setName(name);

}

else {

throw new UnauthorizedException();

}

}

...

} 而DbForum才是接口Forum的真正实现,以修改论坛名称为例:

public class DbForum implements Forum, Cacheable {

...

public void setName(String name) throws ForumAlreadyExistsException {

....

http:// = name;

//这里真正将新名称保存到数据库中

saveToDb();

....

}

...

}

凡是涉及到对论坛名称修改这一事件,其他程序都首先得和ForumProxy打交道,由ForumProxy决定是否有权限做某一样事情,ForumProxy是个名副其实的"网关","安全代理系统".

在平时应用中,无可避免总要涉及到系统的授权或安全体系,不管你有无意识的使用Proxy,实际你已经在使用Proxy了. 我们继续结合Jive谈入深一点,下面要涉及到工厂模式了,如果你不了解工厂模式,请看我的另外一篇文章:设计模式之

我们已经知道,使用Forum需要通过ForumProxy,Jive中创建一个Forum是使用Factory模式,有一个总的抽象类ForumFactory,在这个抽象类中,调用ForumFactory是通过getInstance()方法实现,这里使用了Singleton(也是设计模式之一,由于介绍文章很多,我就不写了),getInstance()返回的是ForumFactoryProxy.

为什么不返回ForumFactory,而返回ForumFactory的实现ForumFactoryProxy?

原因是明显的,需要通过代理确定是否有权限创建forum.

在ForumFactoryProxy中我们看到代码如下:

public class ForumFactoryProxy extends ForumFactory {

protected ForumFactory factory;

protected Authorization authorization;

protected ForumPermissions permissions;

public ForumFactoryProxy(Authorization authorization, ForumFactory factory,