转几篇板桥里人的文章，大家看看吧(0分)

设计模式(Patterns in Java)
Java提供了丰富的API，同时又有强大的数据库系统作底层支持，那么我们的编程似乎变成了类似积木的简单"拼凑"和调用，甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至.
在真正可复用的面向对象编程中,GoF的《设计模式》为我们提供了一套可复用的面向对象技术,再配合Refactoring(重构方法),所以很少存在简单重复的工作,加上Java代码的精炼性和面向对象纯洁性(设计模式是java的灵魂),编程工作将变成一个让你时刻体验创造快感的激动人心的过程.
为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解GoF的《设计模式》。由于原著都是以C++为例, 以Java为例的设计模式基本又都以图形应用为例,而我们更关心Java在中间件等服务器方面的应用,因此,本站所有实例都是非图形应用,并且顺带剖析Jive论坛系统.同时为降低理解难度，尽量避免使用UML图.
如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序员的必备条件.
整个设计模式贯穿一个原理:面对接口编程，而不是面对实现.目标原则是:降低耦合,增强灵活性.
1:前言
学习GoF设计模式的重要性
建筑和软件中模式之异同

2:GoF设计模式
A.创建模式 设计模式之Factory(工厂方法和抽象工厂)
使用工厂模式就象使用new一样频繁.
设计模式之Prototype(原型)
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
设计模式之Builder
汽车由车轮 方向盘 发动机很多部件组成，同时，将这些部件组装成汽车也是一件复杂的工作，Builder模式就是将这两种情况分开进行。
设计模式之Singleton(单态)
保证一个类只有一个实例,并提供一个访问它的全局访问点
B.结构模式 设计模式之Facade
可扩展的使用JDBC针对不同的数据库编程,Facade提供了一种灵活的实现.
设计模式之Proxy
以Jive为例,剖析代理模式在用户级别授权机制上的应用
设计模式之Adapter
使用类再生的两个方式:组合(new)和继承(extends),这个已经在"thinking in java"中提到过.
设计模式之Composite
就是将类用树形结构组合成一个单位.你向别人介绍你是某单位，你是单位中的一个元素，别人和你做买卖，相当于和单位做买卖。文章中还对Jive再进行了剖析。
设计模式之Decorator
Decorator是个油漆工,给你的东东的外表刷上美丽的颜色.
设计模式之Bridge
将"牛郎织女"分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合)
设计模式之Flyweight
提供Java运行性能,降低小而大量重复的类的开销.
C.行为模式 设计模式之Template
实际上向你介绍了为什么要使用Java 抽象类,该模式原理简单,使用很普遍.
设计模式之Memento
很简单一个模式,就是在内存中保留原来数据的拷贝.
设计模式之Observer
介绍如何使用Java API提供的现成Observer
设计模式之Chain of Responsibility
各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个.
设计模式之Command
什么是将行为封装,Command是最好的说明.
设计模式之State
状态是编程中经常碰到的实例,将状态对象化,设立状态变换器,便可在状态中轻松切换.
设计模式之Strategy
不同算法各自封装,用户端可随意挑选需要的算法.
设计模式之Mediator
Mediator很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以.
设计模式之Interpreter
主要用来对语言的分析,应用机会不多.
设计模式之Visitor
访问者在进行访问时,完成一系列实质性操作,而且还可以扩展.
设计模式之Iterator
这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中，直接使用Iterator进行对象遍历。

3:英文资料
Thinking in Patterns with Java Thinking in Java的作者Eckel又一著作!
http://www.bqlr.com/designpatterns/TIPatterns/html/Index.html
CMSC491D Design Patterns In Java
http://www.research.umbc.edu/%7Etarr/cs491/fall00/cs491.html
Overview of Design Patterns 精确定义各个模式以及他们的关系
http://www.mindspring.com/%7Emgrand/pattern_synopses.htm
Design Patterns Java Companion
http://www.patterndepot.com/put/8/JavaPatterns.htm
http://www.bqlr.com/books/ejbdesignpatterns.pdf
EJB设计模式(英文) 从设计模式去理解EJB或J2EE我认为是个非常有效的办法.

学习GoF设计模式的重要性
板桥里人 http://www.jdon.com 2002/05/24
GoF的《设计模式》也许你没有听说过,但是《Thingking in Java》(Java编程思想)你应该知道甚至读过吧！
在浏览《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的设计模式。虽然它是隐性，但不是可以越过的。
在著名的EJB领域顶尖的专家Richard Monson-Haefel的个人网站:www.EJBNow.com中Richard极力推荐的几本书中就有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.
翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补!

建筑和软件中模式之异同
板桥里人 http://www.jdon.com 2002年6月26日
CSDN的透明特别推崇《建筑的永恒之道》,认为从中探寻到软件的永恒之道,并就"设计模式"写了专门文章《探寻软件的永恒之道 》,其中很多观点我看了很受启发,以前我也将"设计模式" 看成一个简单的解决方案,没有从一种高度来看待"设计模式"在软件中地位,下面是我自己的一些想法:
建筑和软件某些地方是可以来比喻的
特别是中国传统建筑,那是很讲模式的,这些都是传统文化使然,比如京剧 一招一式都有套路;中国画,也有套路,树应该怎么画法?有几种画法?艺术大家通常是创造出自己的套路,比如明末清初,水墨画法开始成熟,这时画树就不用勾勒这个模式了,而是一笔下去,浓淡几个叶子,待毛笔的水墨要干枯时,画一下树干,这样,一个活生写意的树就画出来.
我上面这些描述其实都是一种模式,创建模式的人是大师,但是拘泥于模式的人永远是工匠.
再回到传统建筑中,中国的传统建筑是过分注重模式了,所以建筑风格发展不大,基本分南北两派,大家有个感觉,旅游时,到南方,你发现古代名居建筑都差不多;北方由于受满人等少数民族的影响,在建筑色彩上有些与南方迥异,但是很多细节地方都差不多.这些都是模式的体现.
由于建筑受材料和功用以及费用的影响,所用模式种类不多,这点是和软件很大的不同.
正因为这点不同,导致建筑的管理模式和软件的管理模式就有很多不同, 有些人认识不到这点,就产生了可以大量使用"软件蓝领"的想法,因为他羡慕建筑中"民工"的低成本.
要知道软件还有一个与建筑截然相反的责任和用途,那就是:现代社会中,计划感不上变化,竞争激烈,所有一切变幻莫测,要应付所有这些变化,首推信息技术中的软件,只有软件能够帮助人类去应付各种变化.而这点正好与建筑想反,建筑是不能帮助人类去应付变化的,(它自己反而要求稳固,老老实实帮助人遮风避雨,总不能叫人类在露天或树叶下打开电脑编软件吧).
软件要帮助人类去应付变化,这是软件的首要责任,所以,软件中模式产生的目的就和建筑不一样了,建筑中的模式产生可以因为很多原因:建筑大师的创意;材料的革新等;建筑中这些模式一旦产生,容易发生另外一个缺点,就是有时会阻碍建筑本身的发展,因为很多人会不思创造,反复使用老的模式进行设计,阻碍建筑的发展.
但是在软件中,这点正好相反,软件模式的产生是因为变化的东西太多,为减轻人类的负担,将一些不变的东西先用模式固化,这样让人类可以更加集中精力对付变化的东西,所以在软件中大量反复使用模式(我个人认为这样的软件就叫框架软件了,比如J2EE),不但没阻碍软件的发展,反而是推动了软件的发展.因为其他使用这套软件的人就可以将更多精力集中在对付那些无法用模式的应用上来.
可以关于建筑和软件中的模式作用可以总结如下:
在软件中,模式是帮助人类向"变化"战斗,但是在软件中还需要和'变化'直接面对面战斗的武器:人的思维,特别是创造 分析思维等等，这些是软件真正的灵魂，这种思维可以说只要有实践需求(如有新项目)就要求发生，发生频度高，人类的创造或分析思维决定了软件的质量和特点。
而在建筑中,模式可以构成建筑全部知识，当有新的需求(如有新项目)，一般使用旧的模式都可以完成，因此对人类的创造以及分析思维不是每个项目都必须的，也不是非常重要的，对创造性的思维的需求只是属于锦上添花（除非人类以后离开地球居住了〕。

设计模式之Factory

板桥里人 http://www.jdon.com 2002/4/6/


定义:提供创建对象的接口.


为何使用?
工厂模式是我们最常用的模式了,著名的Jive论坛系统,就大量使用了工厂模式.


为什么说工厂模式是最常用,因为工厂模式就相当于创建对象的new. 工厂模式就是用来创建对象的.


比如我们有一个类Sample 我们要创建Sample的对象:


Sample sample=new Sample();


如果我们要在创建sample之前做点事情,比如,赋值等,可以使用Sample的构造函数:


Sample sample=new Sample(参数);


如果创建sample时做的事情不是如赋值这样简单的事,可能是很长一段代码,如果也写入构造函数中,那明显的就违背了面向对象的原则.封装(Encapsulation)和分派(Delegation);


我们需要将创建实例的责任与使用实例的责任分开, 使得语句


Sample sample=new Sample(参数);


就是简单的责任:使用Sample这个实例;至于创建Sample的任务就交给了Factory工厂模式.


还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.


现在Sample是接口,有两个子类MySample 和HisSample .我们要实例化他们时,如下:


Sample mysample=new MySample();

Sample hissample=new HisSample();


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


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


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





public class Factory{


　　public static Sample creator(){


　　....
　　if (which==1)
　　　　return new MySample();

　　else
if (which==2)
　　　　return new HisSample();


　　}


}








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


Sample sample=Factory.creator();


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


好了,言归正传,既然不可避免使用factory,那我们就认识一下工厂模式.


如何使用?
工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory).



上例中,我们使用的是简单的工厂方法. 这两个模式没有很明显的区别,区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,我们就可能要将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现:







public abstract class Factory{


　　public abstract Sample creator();




　　public abstract Sample2 creator();


}


public class SimpleFactory extends Factory{


　　public Sample creator(){
　　　　......
　　}


　　public Sample2 creator(){
　　　　......
　　}





}


public class BombFactory extends Factory{


　　public Sample creator(){
　　　　......
　　}


　　public Sample2 creator(){
　　　　......
　　}








}








上例中我们只有一类产品接口 Sample , 工厂方法和抽象工厂可以创建多个产品接口的实例,比如Sample2 Sample3
FactoryMethod往往只是创建单个的实例。Abstract Factory创建一系列的实例组，这些实例彼此相关。


举例1


下图是来自天极网"
阎宏"的 爪哇语言抽象工厂创立性模式介绍
中的抽象工厂图:



在这张图中, 有两类产品接口interface RAM 和interface CPU;
同时有两个创建方法:MacProducer和PCProducer,这两个创建方法中都有createCPU()和createRAM(),返回的实例对象组是CPU和RAM,
这是分别来自两类产品接口,表面彼此是相关的.因此它是抽象工厂.


举例2


我们以Jive的ForumFactory为例:





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;

　　　　　　　　　　}
　　　　　　　　}
　　　　　　}
　　　　}



　　　　//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,类似网关的概念,可以很好的达到这个效果.



好了.经过上述简单描述,你对工厂模式应该有个简单的印象,如果你要钻研工厂模式,网络上有很多英文资料,不过我觉得过分钻研也没有必要,主要是使用实践,实际使用中工厂模式的变种很多,只要你知道这样一个大概思路,相信在实践中你会是工厂模式的设计创建高手!

设计模式之Prototype(原型)
板桥里人 http://www.jdon.com 2002/05/07
定义:
用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.
Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。
如何使用?
因为Java中的提供clone()方法来实现对象的克隆(具体了解clone()按这里),所以Prototype模式实现一下子变得很简单.
以勺子为例：
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");
　　}
}

public class SaladSpoon extends AbstractSpoon
{
　　public SaladSpoon()
　　{
　　　　setSpoonName("Salad Spoon");
　　}
}

调用Prototype模式很简单:
AbstractSpoon spoon = new SoupSpoon();
AbstractSpoon spoon = new SaladSpoon();

当然也可以结合工厂模式来创建AbstractSpoon实例。
在Java中Prototype模式变成clone()方法的使用，由于Java的纯洁的面向对象特性，使得在Java中使用设计模式变得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如Interator遍历模式。

设计模式之Builder
板桥里人 http://www.jdon.com 2002/05/07
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();

　　}
}

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();

Bridger模式的应用
在Java实际使用中,我们经常用到"池"(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池.
"池"实际是一段内存,当池中有一些复杂的资源的"断肢"(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这些"断肢",将提高内存使用效率,提高池的性能.修改Builder模式中Director类使之能诊断"断肢"断在哪个部件上,再修复这个部件.
具体英文文章见:Recycle broken objects in resource pools

http://www.javaworld.com/javaworld/javatips/jw-javatip78-p2.html#resources

设计模式之Singleton(单态)
板桥里人 http://www.jdon.com 2002/05/07
定义:
Singleton模式主要作用是保证在Java应用程序中，一个Class只有一个实例存在。
一个实例表示是单线程，在很多操作中，比如建立目录 数据库连接都需要单线程操作，Singleton模式经常用于控制对系统资源的控制,我们常常看到工厂模式中工厂方法也用Singleton模式实现的.
如何使用?
一般Singleton模式通常有几种形式:
public class Singleton {
　　private static Singleton _instance = new Singleton();

　　public static Singleton getInstance() {
　　　　return _instance;
　　}
}
调用方法：
Singleton.getInstance()

第二种形式:
public class Singleton {
　　private static Singleton _instance = null;

　　public static Singleton getInstance() {
　　　　if (_instance==null)
　　　　　　_instancenew Singleton()
　　　　return _instance;
　　}
}
调用方法：
Singleton.getInstance()

Singleton模式在创建对象时使用较多，使用它也比较简单。

设计模式之Proxy(代理)
板桥里人banq http://www.jdon.com 2002/04/21/
理解并使用设计模式,能够培养我们良好的面向对象编程习惯,同时在实际应用中,可以如鱼得水,享受游刃有余的乐趣.
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.
*/
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;
}
.....
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 {
　　....
　　this.name = name;
　　//这里真正将新名称保存到数据库中
　　saveToDb();

　　....
}

...
}

凡是涉及到对论坛名称修改这一事件,其他程序都首先得和ForumProxy打交道,由ForumProxy决定是否有权限做某一样事情,ForumProxy是个名副其实的"网关","安全代理系统".
在平时应用中,无可避免总要涉及到系统的授权或安全体系,不管你有无意识的使用Proxy,实际你已经在使用Proxy了.
我们继续结合Jive谈入深一点,下面要涉及到工厂模式了,如果你不了解工厂模式,请看我的另外一篇文章:设计模式之Factory
我们已经知道,使用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,
　　ForumPermissions permissions)
　　{
　　　　this.factory = factory;
　　　　this.authorization = authorization;
　　　　this.permissions = permissions;
　　}
　　public Forum createForum(String name, String description)
　　　　　　throws UnauthorizedException, ForumAlreadyExistsException
　　{
　　　　//只有系统管理者才可以创建forum
　　　　if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
　　　　　　Forum newForum = factory.createForum(name, description);
　　　　　　return new ForumProxy(newForum, authorization, permissions);
　　　　}
　　　　else
{
　　　　　　throw new UnauthorizedException();
　　}
}

方法createForum返回的也是ForumProxy, Proxy就象一道墙,其他程序只能和Proxy交互操作.
注意到这里有两个Proxy:ForumProxy和ForumFactoryProxy. 代表两个不同的职责:使用Forum和创建Forum;
至于为什么将使用对象和创建对象分开,这也是为什么使用Factory模式的原因所在:是为了"封装" "分派";换句话说,尽可能功能单一化,方便维护修改.
Jive论坛系统中其他如帖子的创建和使用,都是按照Forum这个思路而来的.
以上我们讨论了如何使用Proxy进行授权机制的访问,Proxy还可以对用户隐藏另外一种称为copy-on-write的优化方式.拷贝一个庞大而复杂的对象是一个开销很大的操作,如果拷贝过程中,没有对原来的对象有所修改,那么这样的拷贝开销就没有必要.用代理延迟这一拷贝过程.
比如:我们有一个很大的Collection,具体如hashtable,有很多客户端会并发同时访问它.其中一个特别的客户端要进行连续的数据获取,此时要求其他客户端不能再向hashtable中增加或删除 东东.
最直接的解决方案是:使用collection的lock,让这特别的客户端获得这个lock,进行连续的数据获取,然后再释放lock.
public void foFetches(Hashtable ht){
　　synchronized(ht){
　　　　//具体的连续数据获取动作..
　　}
}

但是这一办法可能锁住Collection会很长时间,这段时间,其他客户端就不能访问该Collection了.
第二个解决方案是clone这个Collection,然后让连续的数据获取针对clone出来的那个Collection操作.这个方案前提是,这个Collection是可clone的,而且必须有提供深度clone的方法.Hashtable就提供了对自己的clone方法,但不是Key和value对象的clone,关于Clone含义可以参考专门文章.
public void foFetches(Hashtable ht){

　　Hashttable newht=(Hashtable)ht.clone();

}
问题又来了,由于是针对clone出来的对象操作,如果原来的母体被其他客户端操作修改了, 那么对clone出来的对象操作就没有意义了.
最后解决方案:我们可以等其他客户端修改完成后再进行clone,也就是说,这个特别的客户端先通过调用一个叫clone的方法来进行一系列数据获取操作.但实际上没有真正的进行对象拷贝,直至有其他客户端修改了这个对象Collection.
使用Proxy实现这个方案.这就是copy-on-write操作.
Proxy应用范围很广,现在流行的分布计算方式RMI和Corba等都是Proxy模式的应用.
更多Proxy应用,见http://www.research.umbc.edu/~tarr/cs491/lectures/Proxy.pdf
Sun公司的 Explore the Dynamic Proxy API Dynamic Proxy Classes

设计模式之Adapter(适配器)
板桥里人 http://www.jdon.com 2002/04/21
定义:
将两个不兼容的类纠合在一起使用，属于结构型模式,需要有Adaptee(被适配者)和Adaptor(适配器)两个身份.
为何使用?
我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或者，我们不愿意为了一个应用而修改各自的接口。 怎么办?
使用Adapter，在这两种接口之间创建一个混合接口(混血儿).
如何使用?
实现Adapter方式,其实"think in Java"的"类再生"一节中已经提到,有两种方式：组合(composition)和继承(inheritance).

假设我们要打桩，有两种类：方形桩 圆形桩.
public class SquarePeg{
　　public void insert(String str){
　　　　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;
　　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方法。

设计模式之Composite(组合)
板桥里人 http://www.jdon.com 2002/04/27
Composite定义:
将对象以树形结构组织起来,以达成“部分－整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性.
Composite比较容易理解，想到Composite就应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象的方法被调用执行时，Composite将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一动百来形容。
所以Composite模式使用到Iterator模式，和Chain of Responsibility模式类似。
Composite好处:
1.使客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关系自己处理的是单个对象还是整个组合结构，这就简化了客户端代码。
2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。
如何使用Composite?
首先定义一个接口或抽象类，这是设计模式通用方式了，其他设计模式对接口内部定义限制不多，Composite却有个规定，那就是要在接口内部定义一个用于访问和管理Composite组合体的对象们（或称部件Component）.
下面的代码是以抽象类定义，一般尽量用接口interface,
public abstract class Equipment
{
　　private String name;
　　//网络价格
　　public abstractdo
uble netPrice();
　　//折扣价格
　　public abstractdo
uble discountPrice();
　　//增加部件方法　　
　　public boolean add(Equipment equipment) { return false;
}
　　//删除部件方法
　　public boolean remove(Equipment equipment) { return false;
}
　　//注意这里，这里就提供一种用于访问组合体类的部件方法。
　　public Iterator iter() { return null;
}
　　
　　public Equipment(final String name) { this.name=name;
}
}
抽象类Equipment就是Component定义，代表着组合体类的对象们,Equipment中定义几个共同的方法。
public class Disk extends Equipment
{
　　public Disk(String name) { super(name);
}
　　//定义Disk网络价格为1
　　publicdo
uble netPrice() { return 1.;
}
　　//定义了disk折扣价格是0.5 对折。
　　publicdo
uble discountPrice() { return .5;
}
}
Disk是组合体内的一个对象，或称一个部件，这个部件是个单独元素( Primitive)。
还有一种可能是，一个部件也是一个组合体，就是说这个部件下面还有'儿子'，这是树形结构中通常的情况，应该比较容易理解。现在我们先要定义这个组合体：
abstract class CompositeEquipment extends Equipment
{
　　private int i=0;
　　//定义一个Vector 用来存放'儿子'
　　private Lsit equipment=new ArrayList();

　　public CompositeEquipment(String name) { super(name);
}
　　public boolean add(Equipment equipment) {
　　　　 this.equipment.add(equipment);
　　　　 return true;
　　 }
　　publicdo
uble netPrice()
　　{
　　　　double netPrice=0.;
　　　　Iterator iter=equipment.iterator();
　　　　for(iter.hasNext())
　　　　　　netPrice+=((Equipment)iter.next()).netPrice();
　　　　return netPrice;
　　}
　　publicdo
uble discountPrice()
　　{
　　　　double discountPrice=0.;
　　　　Iterator iter=equipment.iterator();
　　　　for(iter.hasNext())
　　　　　　discountPrice+=((Equipment)iter.next()).discountPrice();
　　　　return discountPrice;
　　}
　　

　　//注意这里，这里就提供用于访问自己组合体内的部件方法。
　　//上面dIsk 之所以没有，是因为Disk是个单独(Primitive)的元素.
　　public Iterator iter()
　　{
　　　　return equipment.iterator() ;
　　{
　　//重载Iterator方法
　　 public boolean hasNext() { return i　　//重载Iterator方法
　　 public Object next()
　　 {
　　　　if(hasNext())
　　　　　　 return equipment.elementAt(i++);
　　　　else

　　 　　 　 throw new NoSuchElementException();
　　 }
　　
}

上面CompositeEquipment继承了Equipment,同时为自己里面的对象们提供了外部访问的方法,重载了Iterator,Iterator是Java的Collection的一个接口，是Iterator模式的实现.
我们再看看CompositeEquipment的两个具体类:盘盒Chassis和箱子Cabinet，箱子里面可以放很多东西，如底板，电源盒，硬盘盒等；盘盒里面可以放一些小设备，如硬盘 软驱等。无疑这两个都是属于组合体性质的。
public class Chassis extends CompositeEquipment
{
　　 public Chassis(String name) { super(name);
}
　　 publicdo
uble netPrice() { return 1.+super.netPrice();
}
　　 publicdo
uble discountPrice() { return .5+super.discountPrice();
}
}
public class Cabinet extends CompositeEquipment
{
　　 public Cabinet(String name) { super(name);
}
　　 publicdo
uble netPrice() { return 1.+super.netPrice();
}
　　 publicdo
uble discountPrice() { return .5+super.discountPrice();
}
}

至此我们完成了整个Composite模式的架构。
我们可以看看客户端调用Composote代码:
Cabinet cabinet=new Cabinet("Tower");

Chassis chassis=new Chassis("PC Chassis");
//将PC Chassis装到Tower中 (将盘盒装到箱子里)
cabinet.add(chassis);
//将一个10GB的硬盘装到 PC Chassis (将硬盘装到盘盒里)
chassis.add(new Disk("10 GB"));

//调用 netPrice()方法;
System.out.println("netPrice="+cabinet.netPrice());
System.out.println("discountPrice="+cabinet.discountPrice());


上面调用的方法netPrice()或discountPrice()，实际上Composite使用Iterator遍历了整个树形结构,寻找同样包含这个方法的对象并实现调用执行.
Composite是个很巧妙体现智慧的模式，在实际应用中，如果碰到树形结构，我们就可以尝试是否可以使用这个模式。
以论坛为例，一个版(forum)中有很多帖子(message),这些帖子有原始贴，有对原始贴的回应贴，是个典型的树形结构，那么当然可以使用Composite模式，那么我们进入Jive中看看，是如何实现的.
Jive解剖
在Jive中 ForumThread是ForumMessages的容器container(组合体).也就是说，ForumThread类似我们上例中的 CompositeEquipment.它和messages的关系如图：
[thread]
　　 |- [message]
　　 |- [message]
　　 　　 |- [message]
　　 　　 |- [message]
　　 　　 　　 |- [message]
我们在ForumThread看到如下代码：

public interface ForumThread {
　　 ....
　　 public void addMessage(ForumMessage parentMessage, ForumMessage newMessage)
　　 　　 　　 throws UnauthorizedException;
　　 public void deleteMessage(ForumMessage message)
　　 　　 　　 throws UnauthorizedException;

　　
　　 public Iterator messages();
　　 　　 ....
}

类似CompositeEquipment, 提供用于访问自己组合体内的部件方法: 增加 删除 遍历.
结合我的其他模式中对Jive的分析，我们已经基本大体理解了Jive论坛体系的框架，如果你之前不理解设计模式，而直接去看Jive源代码，你肯定无法看懂。

设计模式之Decorator(油漆工)
板桥里人 http://www.jdon.com 2002/04/28
Decorator常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的对象我们称decoratee.这两种实体在Decorator模式中是必须的.

Decorator定义:
动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活.

为什么使用Decorator?
我们通常可以使用继承来实现功能的拓展,如果这些需要拓展的功能的种类很繁多,那么势必生成很多子类,增加系统的复杂性,同时,使用继承实现功能拓展,我们必须可预见这些拓展功能,这些功能是编译时就确定了,是静态的.
使用Decorator的理由是:这些功能需要由用户动态决定加入的方式和时机.Decorator提供了"即插即用"的方法,在运行期间决定何时增加何种功能.
如何使用?
举Adapter中的打桩示例,在Adapter中有两种类:方形桩 圆形桩,Adapter模式展示如何综合使用这两个类,在Decorator模式中,我们是要在打桩时增加一些额外功能,比如,挖坑 在桩上钉木板等,不关心如何使用两个不相关的类.
我们先建立一个接口:
public interface Work
{
　　public void insert();

}

接口Work有一个具体实现:插入方形桩或圆形桩,这两个区别对Decorator是无所谓.我们以插入方形桩为例:
public class SquarePeg implements Work{
　　public void insert(){
　　　　System.out.println("方形桩插入");
　　}
}

现在有一个应用:需要在桩打入前,挖坑,在打入后,在桩上钉木板,这些额外的功能是动态,可能随意增加调整修改,比如,可能又需要在打桩之后钉架子(只是比喻).
那么我们使用Decorator模式,这里方形桩SquarePeg是decoratee(被刷油漆者),我们需要在decoratee上刷些"油漆",这些油漆就是那些额外的功能.
public class Decorator implements Work{
　　private Work work;
　　//额外增加的功能被打包在这个List中
　　private ArrayList others = new ArrayList();

　　//在构造器中使用组合new方式,引入Work对象;
　　public Decorator(Work work)
　　{
　　　　this.work=work;
　　
　　　　others.add("挖坑");

　　　　others.add("钉木板");
　　}
　　public void insert(){
　　　　newMethod();
　　}
　　
　　//在新方法中,我们在insert之前增加其他方法,这里次序先后是用户灵活指定的 　　
　　public void newMethod()
　　{
　　　　otherMethod();
　　　　work.insert();

　　}

　　public void otherMethod()
　　{
　　　　ListIterator listIterator = others.listIterator();
　　　　while (listIterator.hasNext())
　　　　{
　　　　　　System.out.println(((String)(listIterator.next())) + " 正在进行");
　　　　}
　　}

}

在上例中,我们把挖坑和钉木板都排在了打桩insert前面,这里只是举例说明额外功能次序可以任意安排.
好了,Decorator模式出来了,我们看如何调用:
Work squarePeg = new SquarePeg();
Work decorator = new Decorator(squarePeg);
decorator.insert();

Decorator模式至此完成.
如果你细心,会发现,上面调用类似我们读取文件时的调用:
FileReader fr = new FileReader(filename);
BufferedReader br = new BufferedReader(fr);

实际上Java 的I/O API就是使用Decorator实现的,I/O变种很多,如果都采取继承方法,将会产生很多子类,显然相当繁琐.
Jive中的Decorator实现
在论坛系统中,有些特别的字是不能出现在论坛中如"打倒XXX",我们需要过滤这些"反动"的字体.不让他们出现或者高亮度显示.
在IBM Java专栏中专门谈Jive的文章中,有谈及Jive中ForumMessageFilter.java使用了Decorator模式,其实,该程序并没有真正使用Decorator,而是提示说:针对特别论坛可以设计额外增加的过滤功能,那么就可以重组ForumMessageFilter作为Decorator模式了.
所以,我们在分辨是否真正是Decorator模式,以及会真正使用Decorator模式,一定要把握好Decorator模式的定义,以及其中参与的角色(Decoratee 和Decorator).

设计模式之Bridge
板桥里人 http://www.jdon.com 2002/05/01
Bridge定义 :
将抽象和行为划分开来,各自独立,但能动态的结合.
为什么使用?
通常,当一个抽象类或接口有多个具体实现(concrete subclass),这些concrete之间关系可能有以下两种:
1. 这多个具体实现之间恰好是并列的,如前面举例,打桩,有两个concrete class:方形桩和圆形桩;这两个形状上的桩是并列的,没有概念上的重复,那么我们只要使用继承就可以了.
2.实际应用上,常常有可能在这多个concrete class之间有概念上重叠.那么需要我们把抽象共同部分和行为共同部分各自独立开来,原来是准备放在一个接口里,现在需要设计两个接口,分别放置抽象和行为.
例如,一杯咖啡为例,有中杯和大杯之分,同时还有加奶 不加奶之分. 如果用单纯的继承,这四个具体实现(中杯 大杯 加奶 不加奶)之间有概念重叠,因为有中杯加奶,也有中杯不加奶, 如果再在中杯这一层再实现两个继承,很显然混乱,扩展性极差.那我们使用Bridge模式来实现它.
如何实现?
以上面提到的咖啡 为例. 我们原来打算只设计一个接口(抽象类),使用Bridge模式后,我们需要将抽象和行为分开,加奶和不加奶属于行为,我们将它们抽象成一个专门的行为接口.
先看看抽象部分的接口代码:

public abstract class Coffee
{
　　CoffeeImp coffeeImp;

　　public void setCoffeeImp() {
　　　　this.CoffeeImp = CoffeeImpSingleton.getTheCoffeImp();
　　}
　　public CoffeeImp getCoffeeImp() {return this.CoffeeImp;}
　　public abstract void pourCoffee();
}

其中CoffeeImp 是加不加奶的行为接口,看其代码如下:
public abstract class CoffeeImp
{
　　public abstract void pourCoffeeImp();
}

现在我们有了两个抽象类,下面我们分别对其进行继承,实现concrete class:
//中杯
public class MediumCoffee extends Coffee
{
　　public MediumCoffee() {setCoffeeImp();}
　　public void pourCoffee()
　　{
　　　　CoffeeImp coffeeImp = this.getCoffeeImp();
　　　　//我们以重复次数来说明是冲中杯还是大杯 ,重复2次是中杯
　　　　for (int i = 0;
i < 2;
i++)
　　　　{
　　　　　　coffeeImp.pourCoffeeImp();
　　　　}
　　
　　}
}

//大杯
public class SuperSizeCoffee extends Coffee
{
　　public SuperSizeCoffee() {setCoffeeImp();}
　　public void pourCoffee()
　　{
　　　　CoffeeImp coffeeImp = this.getCoffeeImp();
　　　　//我们以重复次数来说明是冲中杯还是大杯 ,重复5次是大杯
　　　　for (int i = 0;
i < 5;
i++)
　　　　{
　　　　　　coffeeImp.pourCoffeeImp();
　　　　}
　　
　　}
}

上面分别是中杯和大杯的具体实现.下面再对行为CoffeeImp进行继承:
//加奶
public class MilkCoffeeImp extends CoffeeImp
{
　　MilkCoffeeImp() {}
　　public void pourCoffeeImp()
　　{
　　　　System.out.println("加了美味的牛奶");
　　}
}

//不加奶
public class FragrantCoffeeImp extends CoffeeImp
{
　　FragrantCoffeeImp() {}
　　public void pourCoffeeImp()
　　{
　　　　System.out.println("什么也没加,清香");
　　}
}

Bridge模式的基本框架我们已经搭好了,别忘记定义中还有一句:动态结合,我们现在可以喝到至少四种咖啡:
1.中杯加奶
2.中杯不加奶
3.大杯加奶
4.大杯不加奶
看看是如何动态结合的,在使用之前,我们做个准备工作,设计一个单态类(Singleton)用来hold当前的CoffeeImp:
public class CoffeeImpSingleton
{
　　private static CoffeeImp coffeeImp;

　　public CoffeeImpSingleton(CoffeeImp coffeeImpIn)
　　 {this.coffeeImp = coffeeImpIn;}
　　public static CoffeeImp getTheCoffeeImp()
　　{
　　　　return coffeeImp;
　　}
}

看看中杯加奶 和大杯加奶 是怎么出来的:
//拿出牛奶
CoffeeImpSingleton coffeeImpSingleton = new CoffeeImpSingleton(new MilkCoffeeImp());

//中杯加奶
MediumCoffee mediumCoffee = new MediumCoffee();
mediumCoffee.pourCoffee();

//大杯加奶
SuperSizeCoffee superSizeCoffee = new SuperSizeCoffee();
superSizeCoffee.pourCoffee();

注意: Bridge模式的执行类如CoffeeImp和Coffee是一对一的关系, 正确创建CoffeeImp是该模式的关键,
Bridge模式在EJB中的应用
EJB中有一个Data Access Object (DAO)模式,这是将商业逻辑和具体数据资源分开的,因为不同的数据库有不同的数据库操作.将操作不同数据库的行为独立抽象成一个行为接口DAO.如下:
1.Business Object (类似Coffee)
实现一些抽象的商业操作:如寻找一个用户下所有的订单
涉及数据库操作都使用DAOImplementor.
2.Data Access Object (类似CoffeeImp)
一些抽象的对数据库资源操作
3.DAOImplementor 如OrderDAOCS, OrderDAOOracle, OrderDAOSybase(类似MilkCoffeeImp FragrantCoffeeImp)
具体的数据库操作,如"INSERT INTO "等语句,OrderDAOOracle是Oracle OrderDAOSybase是Sybase数据库.
4.数据库 (Cloudscape, Oracle, or Sybase database via JDBC API)

好！[][][][][]

设计模式之Flyweight(享元)
板桥里人 http://www.jdon.com 2002/05/02
Flyweight定义:
避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类).
为什么使用?
面向对象语言的原则就是一切都是对象,但是如果真正使用起来,有时对象数可能显得很庞大,比如,字处理软件,如果以每个文字都作为一个对象,几千个字,对象数就是几千,无疑耗费内存,那么我们还是要"求同存异",找出这些对象群的共同点,设计一个元类,封装可以被共享的类,另外,还有一些特性是取决于应用(context),是不可共享的,这也Flyweight中两个重要概念内部状态intrinsic和外部状态extrinsic之分.
说白点,就是先捏一个的原始模型,然后随着不同场合和环境,再产生各具特征的具体模型,很显然,在这里需要产生不同的新对象,所以Flyweight模式中常出现Factory模式.Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个Flyweight pool(模式池)来存放内部状态的对象.
Flyweight模式是一个提高程序效率和性能的模式,会大大加快程序的运行速度.应用场合很多:比如你要从一个数据库中读取一系列字符串,这些字符串中有许多是重复的,那么我们可以将这些字符串储存在Flyweight池(pool)中.
如何使用?

我们先从Flyweight抽象接口开始:

public interface Flyweight
{
　　public void operation( ExtrinsicState state );
}
//用于本模式的抽象数据类型(自行设计)
public interface ExtrinsicState { }

下面是接口的具体实现(ConcreteFlyweight) ,并为内部状态增加内存空间, ConcreteFlyweight必须是可共享的,它保存的任何状态都必须是内部(intrinsic),也就是说,ConcreteFlyweight必须和它的应用环境场合无关.
public class ConcreteFlyweight implements Flyweight {
　　private IntrinsicState state;
　　
　　public void operation( ExtrinsicState state )
　　{
　　　　　　//具体操作
　　}
}

当然,并不是所有的Flyweight具体实现子类都需要被共享的,所以还有另外一种不共享的ConcreteFlyweight:
public class UnsharedConcreteFlyweight implements Flyweight {
　　public void operation( ExtrinsicState state ) { }
}

Flyweight factory负责维护一个Flyweight池(存放内部状态),当客户端请求一个共享Flyweight时,这个factory首先搜索池中是否已经有可适用的,如果有,factory只是简单返回送出这个对象,否则,创建一个新的对象,加入到池中,再返回送出这个对象.池

public class FlyweightFactory {
　　//Flyweight pool
　　private Hashtable flyweights = new Hashtable();

　　public Flyweight getFlyweight( Object key ) {

　　　　Flyweight flyweight = (Flyweight) flyweights.get(key);

　　　　if( flyweight == null ) {
　　　　　　//产生新的ConcreteFlyweight
　　　　　　flyweight = new ConcreteFlyweight();
　　　　　　flyweights.put( key, flyweight );
　　　　}

　　　　return flyweight;
　　}
}

至此,Flyweight模式的基本框架已经就绪,我们看看如何调用:
FlyweightFactory factory = new FlyweightFactory();
Flyweight fly1 = factory.getFlyweight( "Fred" );
Flyweight fly2 = factory.getFlyweight( "Wilma" );
......

从调用上看,好象是个纯粹的Factory使用,但奥妙就在于Factory的内部设计上.
Flyweight模式在XML等数据源中应用
我们上面已经提到,当大量从数据源中读取字符串,其中肯定有重复的,那么我们使用Flyweight模式可以提高效率,以唱片CD为例,在一个XML文件中,存放了多个CD的资料.
每个CD有三个字段:
1.出片日期(year)
2.歌唱者姓名等信息(artist)
3.唱片曲目 (title)
其中,歌唱者姓名有可能重复,也就是说,可能有同一个演唱者的多个不同时期 不同曲目的CD.我们将"歌唱者姓名"作为可共享的ConcreteFlyweight.其他两个字段作为UnsharedConcreteFlyweight.
首先看看数据源XML文件的内容:




1978
Eno, Brian


1950
Holiday, Billie


1977
Eno, Brian

.......



虽然上面举例CD只有3张,CD可看成是大量重复的小类,因为其中成分只有三个字段,而且有重复的(歌唱者姓名).
CD就是类似上面接口 Flyweight:

public class CD {
　　private String title;
　　private int year;
　　private Artist artist;

　　public String getTitle() {　　return title;　}
　　public int getYear() {　　　　return year;　　}
　　public Artist getArtist() {　　　　return artist;　　}
　　public void setTitle(String t){　　　　title = t;}
　　public void setYear(int y){year = y;}
　　public void setArtist(Artist a){artist = a;}
}

将"歌唱者姓名"作为可共享的ConcreteFlyweight:
public class Artist {

　　//内部状态
　　private String name;

　　// note that Artist is immutable.
　　String getName(){return name;}

　　Artist(String n){
　　　　name = n;
　　}
}

再看看Flyweight factory,专门用来制造上面的可共享的ConcreteFlyweight:Artist
public class ArtistFactory {
　　Hashtable pool = new Hashtable();

　　Artist getArtist(String key){

　　　　Artist result;
　　　　result = (Artist)pool.get(key);
　　　　////产生新的Artist
　　　　if(result == null) {
　　　　　　result = new Artist(key);
　　　　　　pool.put(key,result);
　　　　　　
　　　　}
　　　 return result;
　 }
}

当你有几千张甚至更多CD时,Flyweight模式将节省更多空间,共享的flyweight越多,空间节省也就越大.

设计模式之Template
板桥里人 http://www.jdon.com 2002/05/05
Template定义:
定义一个操作中算法的骨架,将一些步骤的执行延迟到其子类中.
其实Java的抽象类本来就是Template模式,因此使用很普遍.而且很容易理解和使用,我们直接以示例开始:
public abstract class Benchmark
{
　　/**
　　* 下面操作是我们希望在子类中完成
　　*/
　　public abstract void benchmark();
　　/**
　　* 重复执行benchmark次数
　　*/
　　public final long repeat (int count) {
　　　　if (count <= 0)
　　　　　　return 0;
　　　　else
{
　　　　　　long startTime = System.currentTimeMillis();

　　　　for (int i = 0;
i < count;
i++)
　　　　　　benchmark();

　　　　long stopTime = System.currentTimeMillis();
　　　　return stopTime - startTime;
　　}
}
}

在上例中,我们希望重复执行benchmark()操作,但是对benchmark()的具体内容没有说明,而是延迟到其子类中描述:
public class MethodBenchmark extends Benchmark
{
　　/**
　　* 真正定义benchmark内容
　　*/
　　public void benchmark() {
　　　　for (int i = 0;
i < Integer.MAX_value;
i++){
　　　 　　System.out.printtln("i="+i);　 　　
　　　 }
　　}
}

至此,Template模式已经完成,是不是很简单?看看如何使用:
Benchmark operation = new MethodBenchmark();
long duration = operation.repeat(Integer.parseInt(args[0].trim()));
System.out.println("The operation took " + duration + " milliseconds");


也许你以前还疑惑抽象类有什么用,现在你应该彻底明白了吧? 至于这样做的好处,很显然啊,扩展性强,以后Benchmark内容变化,我只要再做一个继承子类就可以,不必修改其他应用代码.

设计模式之Memento(备忘机制)

板桥里人 http://www.jdon.com 2002/05/05


Memento定义:
memento是一个保存另外一个对象内部状态拷贝的对象.这样以后就可以将该对象恢复到原先保存的状态.


Memento模式相对也比较好理解,我们看下列代码:



public class Originator {

　　 private int number;

　　private File file = null;


　　public Originator(){}


　　// 创建一个Memento
　　public Memento getMemento(){
　　　　return new Memento(this);

　　}


　　// 恢复到原始值
　　public void setMemento(Memento m){
　　　　 number = m.number;

　　　　 file = m.file;

　　}


}








我们再看看Memento类:





private class Memento implements java.io.Serializable{


　　private int number;


　　private File file = null;


　　public Memento( Originator o){


　　　　number = o.number;

　　　　file = o.file;


　　}


}









可见 Memento中保存了Originator中的number和file的值. 通过调用Originator中number和file值改变的话,通过调用setMemento()方法可以恢复.


Memento模式的缺点是耗费大,如果内部状态很多,再保存一份,无意要浪费大量内存.


Memento模式在Jsp+Javabean中的应用
在Jsp应用中,我们通常有很多表单要求用户输入,比如用户注册,需要输入姓名和Email等, 如果一些表项用户没有填写或者填写错误,我们希望在用户按&amp;quot;提交Submit&amp;quot;后,通过Jsp程序检查,发现确实有未填写项目,则在该项目下红字显示警告或错误,同时,还要显示用户刚才已经输入的表项.


如下图中 First Name是用户已经输入,Last Name没有输入,我们则提示红字警告.:





这种技术的实现,就是利用了Javabean的scope=&amp;quot;request&amp;quot;或scope=&amp;quot;session&amp;quot;特性,也就是Memento模式.


具体示例和代码见 JavaWorld的英文原文
, Javabean表单输入特性参见我的另外一篇文章.

设计模式之Chain of Responsibility(职责链)
板桥里人 http://www.jdon.com 2002/04/21
Chain of Responsibility定义
Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说，来了一个请求，A类先处理，如果没有处理，就传递到B类处理，如果没有处理，就传递到C类处理，就这样象一个链条(chain)一样传递下去。
如何使用?
虽然这一段是如何使用CoR,但是也是演示什么是CoR.
有一个Handler接口:
public interface Handler{
　　public void handleRequest();
}
这是一个处理request的事例， 如果有多种request,比如 请求帮助 请求打印 或请求格式化：
最先想到的解决方案是：在接口中增加多个请求：
public interface Handler{
　　public void handleHelp();
　　public void handlePrint();
　　public void handleFORMat();

}
具体是一段实现接口Handler代码：
public class ConcreteHandler implements Handler{
　　private Handler successor;

　　public ConcreteHandler(Handler successor){
　　this.successor=successor;
}
　　public void handleHelp(){
　　　　//具体处理请求Help的代码
　　　　...
　　}
　　public void handlePrint(){
　　　　//如果是print 转去处理Print
　　　　successor.handlePrint();
　　}
　　public void handleFORMat(){
　　　　//如果是FORMat 转去处理FORMat
　　　　successor.handleFORMat();
　　}
}
一共有三个这样的具体实现类，上面是处理help,还有处理Print 处理FORMat这大概是我们最常用的编程思路。
虽然思路简单明了，但是有一个扩展问题，如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。
第二方案:将每种request都变成一个接口，因此我们有以下代码 ：
public interface HelpHandler{
　　public void handleHelp();
}
public interface PrintHandler{
　　public void handlePrint();
}
public interface FORMatHandler{
　　public void handleFORMat();
}
public class ConcreteHandler
　　implements HelpHandler,PrintHandler,FORMatHandlet{
　　private HelpHandler helpSuccessor;
　　private PrintHandler printSuccessor;
　　private FORMatHandler FORMatSuccessor;

　　public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FORMatHandler 　　　　　　　　　　　　FORMatSuccessor)
　　{
　　　　this.helpSuccessor=helpSuccessor;
　　　　this.printSuccessor=printSuccessor;
　　　　this.FORMatSuccessor=FORMatSuccessor;
　　}
　　public void handleHelp(){
　　　　.......
　　}
　　public void handlePrint(){this.printSuccessor=printSuccessor;}
　　public void handleFORMat(){this.FORMatSuccessor=FORMatSuccessor;}
}
这个办法在增加新的请求request情况下，只是节省了接口的修改量，接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。
解决方案3: 在Handler接口中只使用一个参数化方法：
public interface Handler{
　　public void handleRequest(String request);
}
那么Handler实现代码如下：
public class ConcreteHandler implements Handler{
　　private Handler successor;

　　public ConcreteHandler(Handler successor){
　　　　this.successor=successor;
　　}
　　public void handleRequest(String request){
　　　　if (request.equals("Help")){
　　　　　　//这里是处理Help的具体代码
　　　　}else

　　　　　　//传递到下一个
　　　　　　successor.handle(request);

　　　　}
　　}
}

这里先假设request是String类型，如果不是怎么办？当然我们可以创建一个专门类Request

最后解决方案:接口Handler的代码如下：
public interface Handler{
　　public void handleRequest(Request request);
}
Request类的定义:
public class Request{
　　private String type;

　　public Request(String type){this.type=type;}
　　public String getType(){return type;}
　　public void execute(){
　　　　//request真正具体行为代码
　　}
}
那么Handler实现代码如下：
public class ConcreteHandler implements Handler{
　　private Handler successor;

　　public ConcreteHandler(Handler successor){
　　　　this.successor=successor;
　　}
　　public void handleRequest(Request request){
　　　　if (request instanceof HelpRequest){
　　　　　　//这里是处理Help的具体代码
　　　　}else
if (request instanceof PrintRequst){
　　　　　　request.execute();
　　　　}else

　　　　　　//传递到下一个
　　　　　　successor.handle(request);

　　　　}
　　}
}
这个解决方案就是CoR, 在一个链上,都有相应职责的类,因此叫Chain of Responsibility.
CoR的优点：
因为无法预知来自外界的请求是属于哪种类型，每个类如果碰到它不能处理的请求只要放弃就可以。无疑这降低了类之间的耦合性。
缺点是效率低，因为一个请求的完成可能要遍历到最后才可能完成，当然也可以用树的概念优化。 在Java AWT1.0中，对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后，就使用Observer代替CoR
扩展性差，因为在CoR中，一定要有一个统一的接口Handler.局限性就在这里。

设计模式之Command
板桥里人 http://www.jdon.com 2002/4/23/
Command模式是最让我疑惑的一个模式,我在阅读了很多代码后,才感觉隐约掌握其大概原理,我认为理解设计模式最主要是掌握起原理构造,这样才对自己实际编程有指导作用.Command模式实际上不是个很具体,规定很多的模式,正是这个灵活性,让人有些confuse.
Command定义
不少Command模式的代码都是针对图形界面的,它实际就是菜单命令,我们在一个下拉菜单选择一个命令时,然后会执行一些动作.
将这些命令封装成在一个类中,然后用户(调用者)再对这个类进行操作,这就是Command模式,换句话说,本来用户(调用者)是直接调用这些命令的,如菜单上打开文档(调用者),就直接指向打开文档的代码,使用Command模式,就是在这两者之间增加一个中间者,将这种直接关系拗断,同时两者之间都隔离,基本没有关系了.
显然这样做的好处是符合封装的特性,降低耦合度,Command是将对行为进行封装的典型模式,Factory是将创建进行封装的模式,
从Command模式,我也发现设计模式一个"通病":好象喜欢将简单的问题复杂化, 喜欢在不同类中增加第三者,当然这样做有利于代码的健壮性 可维护性 还有复用性.
如何使用?
具体的Command模式代码各式各样,因为如何封装命令,不同系统,有不同的做法.下面事例是将命令封装在一个Collection的List中,任何对象一旦加入List中,实际上装入了一个封闭的黑盒中,对象的特性消失了,只有取出时,才有可能模糊的分辨出:
典型的Command模式需要有一个接口.接口中有一个统一的方法,这就是"将命令/请求封装为对象":
public interface Command {
　　public abstract void execute ( );
}
具体不同命令/请求代码是实现接口Command,下面有三个具体命令
public class Engineer implements Command {
　　public void execute( ) {
　　　　//do Engineer's command
　　}
}
public class Programmer implements Command {
　　public void execute( ) {
　　　　//do programmer's command
　　}
}
public class Politician implements Command {
　　public void execute( ) {
　　　　//do Politician's command
　　}
}

按照通常做法,我们就可以直接调用这三个Command,但是使用Command模式,我们要将他们封装起来,扔到黑盒子List里去:

public class producer{
　　public static List produceRequests() {
　　　　List queue = new ArrayList();
　　　　queue.add( newdo
mesticEngineer() );
　　　　queue.add( new Politician() );
　　　　queue.add( new Programmer() );
　　　　return queue;
　　}
}

这三个命令进入List中后,已经失去了其外表特征,以后再取出,也可能无法分辨出谁是Engineer 谁是Programmer了,看下面如何调用Command模式:

public class TestCommand {
　　public static void main(String[] args) {
　　　　
　　　　List queue = Producer.produceRequests();
　　　　for (Iterator it = queue.iterator();
it.hasNext();
)
　　　　　　　　//取出List中东东,其他特征都不能确定,只能保证一个特征是100%正确,
　　　　　　　　// 他们至少是接口Command的"儿子".所以强制转换类型为接口Command
　　　　　　　　((Command)it.next()).execute();
　　
　　}
}

由此可见,调用者基本只和接口打交道,不合具体实现交互,这也体现了一个原则,面向接口编程,这样,以后增加第四个具体命令时,就不必修改调用者TestCommand中的代码了.
理解了上面的代码的核心原理,在使用中,就应该各人有自己方法了,特别是在如何分离调用者和具体命令上,有很多实现方法,上面的代码是使用"从List过一遍"的做法.这种做法只是为了演示.

使用Command模式的一个好理由还因为它能实现Undo功能.每个具体命令都可以记住它刚刚执行的动作,并且在需要时恢复.
Command模式在界面设计中应用广泛.Java的Swing中菜单命令都是使用Command模式,由于Java在界面设计的性能上还有欠缺,因此界面设计具体代码我们就不讨论,网络上有很多这样的示例.
参考:
http://www.patterndepot.com/put/8/command.pdf

设计模式之Mediator(中介者)
板桥里人 http://www.jdon.com 2002/05/05
Mediator定义:
用一个中介对象来封装一系列关于对象交互行为.
为何使用Mediator?
各个对象之间的交互操作非常多;每个对象的行为操作都依赖彼此对方,修改一个对象的行为,同时会涉及到修改很多其他对象的行为,如果使用Mediator模式,可以使各个对象间的耦合松散,只需关心和 Mediator的关系,使多对多的关系变成了一对多的关系,可以降低系统的复杂性,提高可修改扩展性.
如何使用?
首先 有一个接口,用来定义成员对象之间的交互联系方式:
public interface Mediator { }
Meiator具体实现,真正实现交互操作的内容:
public class ConcreteMediator implements Mediator {
　　 //假设当前有两个成员.
　　 private ConcreteColleague1 colleague1 = new ConcreteColleague1();
　　 private ConcreteColleague2 colleague2 = new ConcreteColleague2();

　　 ...
}

再看看另外一个参与者:成员,因为是交互行为,都需要双方提供一些共同接口,这种要求在Visitor Observer等模式中都是相同的.
public class Colleague {
　　 private Mediator mediator;
　　 public Mediator getMediator() {
　　 　　 return mediator;
　　 }
　　 public void setMediator( Mediator mediator ) {
　　 　　 this.mediator = mediator;
　　 }
}
public class ConcreteColleague1 { }
public class ConcreteColleague2 { }

每个成员都必须知道Mediator,并且和 Mediator联系,而不是和其他成员联系.
至此,Mediator模式框架完成,可以发现Mediator模式规定不是很多,大体框架也比较简单,但实际使用起来就非常灵活.
Mediator模式在事件驱动类应用中比较多,例如界面设计GUI.;聊天,消息传递等,在聊天应用中,需要有一个MessageMediator,专门负责request/reponse之间任务的调节.
MVC是J2EE的一个基本模式,View Controller是一种Mediator,它是Jsp和服务器上应用程序间的Mediator.

设计模式之Interpreter(解释器)
板桥里人 http://www.jdon.com 2002/05/05
Interpreter定义:
定义语言的文法 ,并且建立一个解释器来解释该语言中的句子.
Interpreter似乎使用面不是很广,它描述了一个语言解释器是如何构成的,在实际应用中,我们可能很少去构造一个语言的文法.我们还是来简单的了解一下:
首先要建立一个接口,用来描述共同的操作.
public interface AbstractExpression {
　　 void interpret( Context context );
}
再看看包含解释器之外的一些全局信息
public interface Context { }
AbstractExpression的具体实现分两种:终结符表达式和非终结符表达式:
public class TerminalExpression implements AbstractExpression {
　　 public void interpret( Context context ) { }
}
对于文法中没一条规则,非终结符表达式都必须的:
public class NonterminalExpression implements AbstractExpression {
　　 private AbstractExpression successor;
　　
　　 public void setSuccessor( AbstractExpression successor ) {
　　　　 this.successor = successor;
　　 }
　　 public AbstractExpression getSuccessor() {
　　　　 return successor;
　　 }
　　 public void interpret( Context context ) { }
}