Java 设计模式


设计模式(Patterns in Java) -- http://www.jdon.com 1 设计模式(Patterns in Java) Java 提供了丰富的 API,同时又有强大的数据库系统作底层支持,那么我们的编程似乎 变成了类似积木的简单"拼凑"和调用,甚至有人提倡"蓝领程序员",这些都是对现代编 程技术的不了解所至. 在真正可复用的面向对象编程中,GoF 的《设计模式》为我们提供了一套可复用的面向对 象技术,再配合 Refactoring(重构方法),所以很少存在简单重复的工作,加上 Java 代码 的精炼性和面向对象纯洁性(设计模式是java 的灵魂),编程工作将变成一个让你时刻体 验创造快感的激动人心的过程. 为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多 人更容易理解 GoF 的《设计模式》。由于原著都是以 C++为例, 以 Java 为例的设计模式 基本又都以图形应用为例,而我们更关心Java 在中间件等服务器方面的应用,因此,本站 所有实例都是非图形应用,并且顺带剖析 Jive 论坛系统.同时为降低理解难度,尽量避 免使用 UML 图. 如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过 了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用 的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序 员的必备条件. 整个设计模式贯穿一个原理:面对接口编程,而不是面对实现.目标原则是:降低耦合,增 强灵活性. 1:前言 学习 GoF 设计模式的重要性 建筑和软件中模式之异同 2:GoF 设计模式 A.创建模式 设计模式之 Factory(工厂方法和抽象工厂) 使用工厂模式就象使用 new 一样频繁. 设计模式之 Prototype(原型) 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的 对象。 设计模式(Patterns in Java) -- http://www.jdon.com 2 设计模式之 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 设计模式(Patterns in Java) -- http://www.jdon.com 3 设计模式之 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 又一 著作! CMSC491D Design Patterns In Java Overview of Design Patterns 精确定义各个模式以及他们的关系 Design Patterns Java Companion EJB 设计模式(英文) 从设计模式去理解EJB或J2EE我认为是个非常有效 的办法. 设计模式(Patterns in Java) -- http://www.jdon.com 4 学习 GoF 设计模式的重要性 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 的设计模式是在这方面开始探索的一块里程碑。 设计模式(Patterns in Java) -- http://www.jdon.com 5 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. 翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受 洗的双重节日),如果你从来没有读过这本书,你会在你的程序教育生涯里存在一个严重裂沟, 所以你应该立即挽救弥补! 设计模式(Patterns in Java) -- http://www.jdon.com 6 设计模式(Patterns in Java) -- http://www.jdon.com 7 建筑和软件中模式之异同 CSDN 的透明特别推崇《建筑的永恒之道》,认为从中探寻到软件的永恒之道,并就"设计模式 "写了专门文章《探寻软件的永恒之道 》,其中很多观点我看了很受启发,以前我也将"设计 模式" 看成一个简单的解决方案,没有从一种高度来看待"设计模式"在软件中地位,下面是 我自己的一些想法: 建筑和软件某些地方是可以来比喻的 特别是中国传统建筑,那是很讲模式的,这些都是传统文化使然,比如京剧 一招一式都有套 路;中国画,也有套路,树应该怎么画法?有几种画法?艺术大家通常是创造出自己的套路,比 如明末清初,水墨画法开始成熟,这时画树就不用勾勒这个模式了,而是一笔下去,浓淡几个 叶子,待毛笔的水墨要干枯时,画一下树干,这样,一个活生写意的树就画出来. 我上面这些描述其实都是一种模式,创建模式的人是大师,但是拘泥于模式的人永远是工匠. 再回到传统建筑中,中国的传统建筑是过分注重模式了,所以建筑风格发展不大,基本分南北 两派,大家有个感觉,旅游时,到南方,你发现古代名居建筑都差不多;北方由于受满人等少数 民族的影响,在建筑色彩上有些与南方迥异,但是很多细节地方都差不多.这些都是模式的体 现. 由于建筑受材料和功用以及费用的影响,所用模式种类不多,这点是和软件很大的不同. 正因为这点不同,导致建筑的管理模式和软件的管理模式就有很多不同, 有些人认识不到这 点,就产生了可以大量使用"软件蓝领"的想法,因为他羡慕建筑中"民工"的低成本. 要知道软件还有一个与建筑截然相反的责任和用途,那就是:现代社会中,计划感不上变化, 竞争激烈,所有一切变幻莫测,要应付所有这些变化,首推信息技术中的软件,只有软件能够 帮助人类去应付各种变化.而这点正好与建筑想反,建筑是不能帮助人类去应付变化的,(它 自己反而要求稳固,老老实实帮助人遮风避雨,总不能叫人类在露天或树叶下打开电脑编软 件吧). 软件要帮助人类去应付变化,这是软件的首要责任,所以,软件中模式产生的目的就和建筑不 一样了,建筑中的模式产生可以因为很多原因:建筑大师的创意;材料的革新等;建筑中这些 模式一旦产生,容易发生另外一个缺点,就是有时会阻碍建筑本身的发展,因为很多人会不思 创造,反复使用老的模式进行设计,阻碍建筑的发展. 但是在软件中,这点正好相反,软件模式的产生是因为变化的东西太多,为减轻人类的负担, 将一些不变的东西先用模式固化,这样让人类可以更加集中精力对付变化的东西,所以在软 件中大量反复使用模式(我个人认为这样的软件就叫框架软件了,比如 J2EE),不但没阻碍软 件的发展,反而是推动了软件的发展.因为其他使用这套软件的人就可以将更多精力集中在 对付那些无法用模式的应用上来. 设计模式(Patterns in Java) -- http://www.jdon.com 8 可以关于建筑和软件中的模式作用可以总结如下: 在软件中,模式是帮助人类向"变化"战斗,但是在软件中还需要和'变化'直接面对面战斗的 武器:人的思维,特别是创造 分析思维等等,这些是软件真正的灵魂,这种思维可以说只要 有实践需求(如有新项目)就要求发生,发生频度高,人类的创造或分析思维决定了软件的质 量和特点。 而在建筑中,模式可以构成建筑全部知识,当有新的需求(如有新项目),一般使用旧的模式 都可以完成,因此对人类的创造以及分析思维不是每个项目都必须的,也不是非常重要的, 对创造性的思维的需求只是属于锦上添花(除非人类以后离开地球居住了)。 设计模式(Patterns in Java) -- http://www.jdon.com 9 设计模式之 Factory 定义:提供创建对象的接口. 为何使用? 工厂模式是我们最常用的模式了,著名的 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 实例的工厂: 设计模式(Patterns in Java) -- http://www.jdon.com 10 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(){ 设计模式(Patterns in Java) -- http://www.jdon.com 11 ...... } public Sample2 creator(){ ...... } } public class BombFactory extends Factory{ public Sample creator(){ ...... } public Sample2 creator(){ ...... } } 上例中我们只有一类产品接口 Sample , 工厂方法和抽象工厂可以创建多个产品接口的实 例,比如 Sample2 Sample3 FactoryMethod 往往只是创建单个的实例。Abstract Factory 创建一系列的实例组,这些实 例彼此相关。 举例 1 下图是来自天极网" 阎宏"的 爪哇语言抽象工厂创立性模式介绍 中的抽象工厂图: 设计模式(Patterns in Java) -- http://www.jdon.com 12 在这张图中, 有两类产品接口 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) { 设计模式(Patterns in Java) -- http://www.jdon.com 13 ...... 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,类似网关的概念,可以很好的达到这个效果. 设计模式(Patterns in Java) -- http://www.jdon.com 14 好了.经过上述简单描述,你对工厂模式应该有个简单的印象,如果你要钻研工厂模式,网络 上有很多英文资料,不过我觉得过分钻研也没有必要,主要是使用实践,实际使用中工厂模式 的变种很多,只要你知道这样一个大概思路,相信在实践中你会是工厂模式的设计创建高手! 设计模式(Patterns in Java) -- http://www.jdon.com 15 设计模式之 Prototype(原型) 定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象. 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"); 设计模式(Patterns in Java) -- http://www.jdon.com 16 } } 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 遍历模式。 设计模式(Patterns in Java) -- http://www.jdon.com 17 设计模式之 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 的内容是如何将部件最后组装成成品: 设计模式(Patterns in Java) -- http://www.jdon.com 18 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: 设计模式(Patterns in Java) -- http://www.jdon.com 19 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 类使之能诊断"断肢"断在哪个部件上,再修复这个部件. 具体英文文章见:Recycle broken objects in resource pools 设计模式(Patterns in Java) -- http://www.jdon.com 20 设计模式之 Singleton(单态) 定义: 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() 设计模式(Patterns in Java) -- http://www.jdon.com 21 Singleton 模式在创建对象时使用较多,使用它也比较简单。 设计模式(Patterns in Java) -- http://www.jdon.com 22 设计模式之 Facade(外观) Facade 的定义: 为子系统中的一组接口提供一个一致的界面. Facade 一个典型应用就是数据库 JDBC 的应用,如下例对数据库的操作: public class DBCompare { Connection conn = null; PreparedStatement prep = null; ResultSet rset = null; try { Class.forName( "" ).newInstance(); conn = DriverManager.getConnection( "" ); String sql = "SELECT * FROM WHERE = ?"; prep = conn.prepareStatement( sql ); prep.setString( 1, "" ); rset = prep.executeQuery(); if( rset.next() ) { System.out.println( rset.getString( "也非常方便,比如从 Mysql 数据库换到 Oracle 数据库,只要更 换 facade 接口中的 driver 就可以. 我们做成了一个 Facade 接口,使用该接口,上例中的程序就可以更改如下: public class DBCompare { 设计模式(Patterns in Java) -- http://www.jdon.com 23 String sql = "SELECT * FROM
WHERE = ?"; try { Mysql msql=new mysql(sql); prep.setString( 1, "" ); rset = prep.executeQuery(); if( rset.next() ) { System.out.println( rset.getString( " Another Green World 1978 Eno, Brian Greatest Hits 1950 Holiday, Billie Taking Tiger Mountain (by strategy) 1977 Eno, Brian ....... 设计模式(Patterns in Java) -- http://www.jdon.com 48 虽然上面举例 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 { 设计模式(Patterns in Java) -- http://www.jdon.com 49 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 越多,空间 节省也就越大. 设计模式(Patterns in Java) -- http://www.jdon.com 50 设计模式之 Template 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 内容 */ 设计模式(Patterns in Java) -- http://www.jdon.com 51 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 内容变化,我只要再做一个继承子类就可以,不必修改其他应 用代码. 设计模式(Patterns in Java) -- http://www.jdon.com 52 设计模式之 Memento(备忘机制) 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; 设计模式(Patterns in Java) -- http://www.jdon.com 53 file = o.file; } } 可见 Memento 中保存了 Originator 中的 number 和 file 的值. 通过调用 Originator 中 number 和 file 值改变的话,通过调用 setMemento()方法可以恢复. Memento 模式的缺点是耗费大,如果内部状态很多,再保存一份,无意要浪费大量内存. Memento 模式在 Jsp+Javabean 中的应用 在Jsp应用中,我们通常有很多表单要求用户输入,比如用户注册,需要输入姓名和Email等, 如果一些表项用户没有填写或者填写错误,我们希望在用户按"提交 Submit"后,通过 Jsp 程 序检查,发现确实有未填写项目,则在该项目下红字显示警告或错误,同时,还要显示用户刚 才已经输入的表项. 如下图中 First Name 是用户已经输入,Last Name 没有输入,我们则提示红字警告.: 设计模式(Patterns in Java) -- http://www.jdon.com 54 这种技术的实现,就是利用了Javabean的scope="request"或scope="session"特性,也就是 Memento 模式. 具体示例和代码见 JavaWorld 的英文原文 , Javabean 表单输入特性参见我的另外一篇文 章. 设计模式(Patterns in Java) -- http://www.jdon.com 55 设计模式之 Observer Java 深入到一定程度,就不可避免的碰到设计模式(design pattern)这一概念,了解设计模 式,将使自己对java中的接口或抽象类应用有更深的理解.设计模式在java的中型系统中应 用广泛,遵循一定的编程模式,才能使自己的代码便于理解,易于交流,Observer(观察者)模 式是比较常用的一个模式,尤其在界面设计中应用广泛,而本站所关注的是 Java 在电子商务 系统中应用,因此想从电子商务实例中分析 Observer 的应用. 虽然网上商店形式多样,每个站点有自己的特色,但也有其一般的共性,单就"商品的变化,以 便及时通知订户"这一点,是很多网上商店共有的模式,这一模式类似 Observer patern. 具体的说,如果网上商店中商品在名称 价格等方面有变化,如果系统能自动通知会员,将是 网上商店区别传统商店的一大特色.这就需要在商品 product 中加入 Observer 这样角色,以 便 product 细节发生变化时,Observer 能自动观察到这种变化,并能进行及时的 update 或 notify 动作. Java 的 API 还为为我们提供现成的 Observer 接口 Java.util.Observer.我们只要直接使用 它就可以. 我们必须 extends Java.util.Observer 才能真正使用它: 1.提供 Add/Delete observer 的方法; 2.提供通知(notisfy) 所有 observer 的方法; //产品类 可供 Jsp 直接使用 UseBean 调用 该类主要执行产品数据库插 设计模式(Patterns in Java) -- http://www.jdon.com 56 入 更新 public class product extends Observable{ private String name; private float price; public String getName(){ return name;} public void setName(){ this.name=name; //设置变化点 setChanged(); notifyObservers(name); } public float getPrice(){ return price;} public void setPrice(){ this.price=price; //设置变化点 setChanged(); notifyObservers(new Float(price)); } //以下可以是数据库更新 插入命令. public void saveToDb(){ ..................... } 我们注意到,在 product 类中 的 setXXX 方法中,我们设置了 notify(通知)方法, 当 Jsp 表 单调用 setXXX(如何调用见我的另外一篇文章),实际上就触发了 notisfyObservers 方法,这 将通知相应观察者应该采取行动了. 下面看看这些观察者的代码,他们究竟采取了什么行动: //观察者 NameObserver 主要用来对产品名称(name)进行观察的 public class NameObserver implements Observer{ private String name=null; public void update(Observable obj,Object arg){ 设计模式(Patterns in Java) -- http://www.jdon.com 57 if (arg instanceof String){ name=(String)arg; //产品名称改变值在 name 中 System.out.println("NameObserver :name changet to "+name); } } } //观察者 PriceObserver 主要用来对产品价格(price)进行观察的 public class PriceObserver implements Observer{ private float price=0; public void update(Observable obj,Object arg){ if (arg instanceof Float){ price=((Float)arg).floatValue(); System.out.println("PriceObserver :price changet to "+price); } } } Jsp 中我们可以来正式执行这段观察者程序: <% 设计模式(Patterns in Java) -- http://www.jdon.com 58 if (request.getParameter("save")!=null) { product.saveToDb(); out.println("产品数据变动 保存! 并已经自动通知客户"); }else{ //加入观察者 product.addObserver(nameobs); product.addObserver(priceobs); %> //request.getRequestURI()是产生本 jsp 的程序名,就是自己调用自己
产品名称: 产品价格: <% } %> 执行改Jsp程序,会出现一个表单录入界面, 需要输入产品名称 产品价格, 点按Submit后, 还是执行该 jsp 的 if (request.getParameter("save")!=null)之间的代码. 由于这里使用了数据 javabeans 的自动赋值概念,实际程序自动执行了 setName setPrice 语句.你会在服务器控制台中发现下面信息:: 设计模式(Patterns in Java) -- http://www.jdon.com 59 NameObserver :name changet to ?????(Jsp 表单中输入的产品名称) PriceObserver :price changet to ???(Jsp 表单中输入的产品价格); 这说明观察者已经在行动了.!! 同时你会在执行 jsp 的浏览器端得到信息: 产品数据变动 保存! 并已经自动通知客户 上文由于使用 jsp 概念,隐含很多自动动作,现将调用观察者的 Java 代码写如下: public class Test { public static void main(String args[]){ Product product=new Product(); NameObserver nameobs=new NameObserver(); PriceObserver priceobs=new PriceObserver(); //加入观察者 product.addObserver(nameobs); product.addObserver(priceobs); product.setName("橘子红了"); product.setPrice(9.22f); } } 你会在发现下面信息:: NameObserver :name changet to 橘子红了 PriceObserver :price changet to 9.22 设计模式(Patterns in Java) -- http://www.jdon.com 60 这说明观察者在行动了.!! 设计模式(Patterns in Java) -- http://www.jdon.com 61 设计模式之 Chain of Responsibility(职责链) 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 的代码 ... } 设计模式(Patterns in Java) -- http://www.jdon.com 62 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; } 设计模式(Patterns in Java) -- http://www.jdon.com 63 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 类的定义: 设计模式(Patterns in Java) -- http://www.jdon.com 64 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.局限性就在这里。 设计模式(Patterns in Java) -- http://www.jdon.com 65 设计模式之 Command 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 { 设计模式(Patterns in Java) -- http://www.jdon.com 66 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( new DomesticEngineer() ); 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(); 设计模式(Patterns in Java) -- http://www.jdon.com 67 } } 由此可见,调用者基本只和接口打交道,不合具体实现交互,这也体现了一个原则,面向接口 编程,这样,以后增加第四个具体命令时,就不必修改调用者 TestCommand 中的代码了. 理解了上面的代码的核心原理,在使用中,就应该各人有自己方法了,特别是在如何分离调用 者和具体命令上,有很多实现方法,上面的代码是使用"从 List 过一遍"的做法.这种做法只 是为了演示. 使用Command模式的一个好理由还因为它能实现Undo功能.每个具体命令都可以记住它刚刚 执行的动作,并且在需要时恢复. Command模式在界面设计中应用广泛.Java的 Swing中菜单命令都是使用Command模式,由于 Java 在界面设计的性能上还有欠缺,因此界面设计具体代码我们就不讨论,网络上有很多这 样的示例. 参考: http://www.patterndepot.com/put/8/command.pdf 设计模式(Patterns in Java) -- http://www.jdon.com 68 设计模式之 State State 的定义: 不同的状态,不同的行为;或者说,每个状态有着相应的行为. 何时使用? State 模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用 If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取 State 模式了. 不只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数 据库系统中出现频率比较高,我们经常会在一个数据表的尾部,加上 property 属性含义的字 段,用以标识记录中一些特殊性质的记录,这种属性的改变(切换)又是随时可能发生的,就有 可能要使用 State. 是否使用? 在实际使用,类似开关一样的状态切换是很多的,但有时并不是那么明显,取决于你的经验和 对系统的理解深度. 这里要阐述的是"开关切换状态" 和" 一般的状态判断"是有一些区别的, " 一般的状态判 断"也是有 if..elseif 结构,例如: if (which==1) state="hello"; else if (which==2) state="hi"; else if (which==3) state="bye"; 这是一个 " 一般的状态判断",state 值的不同是根据 which 变量来决定的,which 和 state 没有关系.如果改成: if (state.euqals("bye")) state="hello"; else if (state.euqals("hello")) state="hi"; else if (state.euqals("hi")) state="bye"; 这就是 "开关切换状态",是将 state 的状态从"hello"切换到"hi",再切换到""bye";在切换 到"hello",好象一个旋转开关,这种状态改变就可以使用 State 模式了. 如果单纯有上面一种将"hello"-->"hi"-->"bye"-->"hello"这一个方向切换,也不一定需要 使用 State 模式,因为 State 模式会建立很多子类,复杂化,但是如果又发生另外一个行为: 将上面的切换方向反过来切换,或者需要任意切换,就需要 State 了. 请看下例: 设计模式(Patterns in Java) -- http://www.jdon.com 69 public class Context{ private Color state=null; public void push(){ //如果当前 red 状态 就切换到 blue if (state==Color.red) state=Color.blue; //如果当前 blue 状态 就切换到 green else if (state==Color.blue) state=Color.green; //如果当前 black 状态 就切换到 red else if (state==Color.black) state=Color.red; //如果当前 green 状态 就切换到 black else if (state==Color.green) state=Color.black; Sample sample=new Sample(state); sample.operate(); } public void pull(){ //与 push 状态切换正好相反 if (state==Color.green) state=Color.blue; else if (state==Color.black) state=Color.green; else if (state==Color.blue) state=Color.red; else if (state==Color.red) state=Color.black; Sample2 sample2=new Sample2(state); sample2.operate(); } } 在上例中,我们有两个动作 push 推和 pull 拉,这两个开关动作,改变了 Context 颜色,至此, 我们就需要使用 State 模式优化它. 另外注意:但就上例,state 的变化,只是简单的颜色赋值,这个具体行为是很简单的,State 适合巨大的具体行为,因此在,就本例,实际使用中也不一定非要使用 State 模式,这会增加 子类的数目,简单的变复杂. 例如: 银行帐户, 经常会在 Open 状态和 Close 状态间转换. 设计模式(Patterns in Java) -- http://www.jdon.com 70 例如: 经典的TcpConnection, Tcp的状态有创建 侦听 关闭三个,并且反复转换,其创建 侦 听 关闭的具体行为不是简单一两句就能完成的,适合使用 State 例如:信箱 POP 帐号, 会有四种状态, start HaveUsername Authorized quit,每个状态对应 的行为应该是比较大的.适合使用 State 例如:在工具箱挑选不同工具,可以看成在不同工具中切换,适合使用 State.如 具体绘图程 序,用户可以选择不同工具绘制方框 直线 曲线,这种状态切换可以使用 State. 如何使用 State 需要两种类型实体参与: 1.state manager 状态管理器 ,就是开关 ,如上面例子的 Context 实际就是一个 state manager, 在 state manager 中有对状态的切换动作. 2.用抽象类或接口实现的父类,,不同状态就是继承这个父类的不同子类. 以上面的 Context 为例.我们要修改它,建立两个类型的实体. 第一步: 首先建立一个父类: public abstract class State{ public abstract void handlepush(Context c); public abstract void handlepull(Context c); public abstract void getcolor(); } 父类中的方法要对应 state manager 中的开关行为,在 state manager 中 本例就是 Context 中,有两个开关动作 push 推和 pull 拉.那么在状态父类中就要有具体处理这两个动 作:handlepush() handlepull(); 同时还需要一个获取push或pull结果的方法getcolor() 下面是具体子类的实现: public class BlueState extends State{ public void handlepush(Context c){ //根据 push 方法"如果是 blue 状态的切换到 green" ; c.setState(new GreenState()); } public void handlepull(Context c){ //根据 pull 方法"如果是 blue 状态的切换到 red" ; 设计模式(Patterns in Java) -- http://www.jdon.com 71 c.setState(new RedState()); } public abstract void getcolor(){ return (Color.blue)} } 同样 其他状态的子类实现如 blue 一样. 第二步: 要重新改写 State manager 也就是本例的 Context: public class Context{ private Sate state=null; //我们将原来的 Color state 改成了新建的 State state; //setState 是用来改变 state 的状态 使用 setState 实现状态的切换 pulic void setState(State state){ this.state=state; } public void push(){ //状态的切换的细节部分,在本例中是颜色的变化,已经封装在子类的 handlepush 中实现,这里无需关心 state.handlepush(this); //因为 sample 要使用 state 中的一个切换结果,使用 getColor() Sample sample=new Sample(state.getColor()); sample.operate(); } public void pull(){ state.handlepull(this); Sample2 sample2=new Sample2(state.getColor()); 设计模式(Patterns in Java) -- http://www.jdon.com 72 sample2.operate(); } } 至此,我们也就实现了 State 的 refactorying 过程. 以上只是相当简单的一个实例,在实际应用中,handlepush 或 handelpull 的处理是复杂的. 参考资源: the State and Stategy How to implement state-dependent behavior The state patterns 设计模式(Patterns in Java) -- http://www.jdon.com 73 设计模式之 Strategy(策略) Strategy 是属于设计模式中 对象行为型模式,主要是定义一系列的算法,把这些算法一个 个封装成单独的类. Stratrgy 应用比较广泛,比如, 公司经营业务变化图, 可能有两种实现方式,一个是线条曲 线,一个是框图(bar),这是两种算法,可以使用 Strategy 实现. 这里以字符串替代为例, 有一个文件,我们需要读取后,希望替代其中相应的变量,然后输出. 关于替代其中变量的方法可能有多种方法,这取决于用户的要求,所以我们要准备几套变量 字符替代方案. 首先,我们建立一个抽象类 RepTempRule 定义一些公用变量和方法: public abstract class RepTempRule{ protected String oldString=""; public void setOldString(String oldString){ this.oldString=oldString; } protected String newString=""; 设计模式(Patterns in Java) -- http://www.jdon.com 74 public String getNewString(){ return newString; } public abstract void replace() throws Exception; } 在 RepTempRule 中 有一个抽象方法 abstract 需要继承明确,这个 replace 里其实是替代的 具体方法. 我们现在有两个字符替代方案, 1.将文本中 aaa 替代成 bbb; 2.将文本中 aaa 替代成 ccc; 对应的类分别是 RepTempRuleOne RepTempRuleTwo public class RepTempRuleOne extends RepTempRule{ public void replace() throws Exception{ //replaceFirst 是 jdk1.4 新特性 newString=oldString.replaceFirst("aaa", "bbbb") System.out.println("this is replace one"); } } public class RepTempRuleTwo extends RepTempRule{ public void replace() throws Exception{ newString=oldString.replaceFirst("aaa", "ccc") System.out.println("this is replace Two"); } 设计模式(Patterns in Java) -- http://www.jdon.com 75 } 第二步:我们要建立一个算法解决类,用来提供客户端可以自由选择算法。 public class RepTempRuleSolve { private RepTempRule strategy; public RepTempRuleSolve(RepTempRule rule){ this.strategy=rule; } public String getNewContext(Site site,String oldString) { return strategy.replace(site,oldString); } public void changeAlgorithm(RepTempRule newAlgorithm) { strategy = newAlgorithm; } } 调用如下: public class test{ ...... public void testReplace(){ //使用第一套替代方案 RepTempRuleSolve solver=new RepTempRuleSolve(new RepTempRuleSimple()); solver.getNewContext(site,context); //使用第二套 solver=new RepTempRuleSolve(new RepTempRuleTwo()); solver.getNewContext(site,context); 设计模式(Patterns in Java) -- http://www.jdon.com 76 } ..... } 我们达到了在运行期间,可以自由切换算法的目的。 实际整个 Strategy 的核心部分就是抽象类的使用,使用 Strategy 模式可以在用户需要变化 时,修改量很少,而且快速. Strategy 和 Factory 有一定的类似,Strategy 相对简单容易理解,并且可以在运行时刻自由 切换。Factory 重点是用来创建对象。 Strategy 适合下列场合: 1.以不同的格式保存文件; 2.以不同的算法压缩文件; 3.以不同的算法截获图象; 4.以不同的格式输出同样数据的图形,比如曲线 或框图 bar 等 设计模式(Patterns in Java) -- http://www.jdon.com 77 设计模式之 Mediator(中介者) 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; } 设计模式(Patterns in Java) -- http://www.jdon.com 78 } public class ConcreteColleague1 { } public class ConcreteColleague2 { } 每个成员都必须知道 Mediator,并且和 Mediator 联系,而不是和其他成员联系. 至此,Mediator 模式框架完成,可以发现 Mediator 模式规定不是很多,大体框架也比较简单, 但实际使用起来就非常灵活. Mediator 模式在事件驱动类应用中比较多,例如界面设计 GUI.;聊天,消息传递等,在聊天应 用中,需要有一个 MessageMediator,专门负责 request/reponse 之间任务的调节. MVC 是 J2EE 的一个基本模式,View Controller 是一种 Mediator,它是 Jsp 和服务器上应用 程序间的 Mediator. 设计模式(Patterns in Java) -- http://www.jdon.com 79 设计模式之 Interpreter(解释器) 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 ) { } } 设计模式(Patterns in Java) -- http://www.jdon.com 80 设计模式之 Visitor Visitor 定义 作用于某个对象群中各个对象的操作. 它可以使你在不改变这些对象本身的情况下,定义作 用于这些对象的新操作. 在 Java 中,Visitor 模式实际上是分离了 collection 结构中的元素和对这些元素进行操作 的行为. 为何使用 Visitor? Java 的 Collection(包括 Vector 和 Hashtable)是我们最经常使用的技术,可是 Collection 好象是个黑色大染缸,本来有各种鲜明类型特征的对象一旦放入后,再取出时,这些类型就消 失了.那么我们势必要用 If 来判断,如: Iterator iterator = collection.iterator() while (iterator.hasNext()) { Object o = iterator.next(); if (o instanceof Collection) messyPrintCollection((Collection)o); else if (o instanceof String) System.out.println("'"+o.toString()+"'"); else if (o instanceof Float) System.out.println(o.toString()+"f"); else System.out.println(o.toString()); } 在上例中,我们使用了 instanceof 来判断 o 的类型. 很显然,这样做的缺点代码 If else if 很繁琐.我们就可以使用 Visitor 模式解决它. 如何使用 Visitor? 针对上例,我们设计一个接口 visitor 访问者: public interface Visitor { public void visitCollection(Collection collection); public void visitString(String string); public void visitFloat(Float float); } 在这个接口中,将我们认为 Collection 有可能的类的类型放入其中. 设计模式(Patterns in Java) -- http://www.jdon.com 81 有了访问者,我们需要被访问者,被访问者就是我们 Collection 的每个元素 Element,我们要 为这些 Element 定义一个可以接受访问的接口(访问和被访问是互动的,只有访问者,被访问 者如果表示不欢迎,访问者就不能访问), 我们定义这个接口叫 Visitable,用来定义一个 Accept 操作,也就是说让 Collection 每个元 素具备可访问性. public interface Visitable { public void accept(Visitor visitor); } 好了,有了两个接口,我们就要定义他们的具体实现(Concrete class): public class ConcreteElement implements Visitable { private String value; public ConcreteElement(String string) { value = string; } //定义 accept 的具体内容 这里是很简单的一句调用 public void accept(Visitor visitor) { visitor.visitString(this); } } 再看看访问者的 Concrete 实现: public class ConcreteVisitor implements Visitor { //在本方法中,我们实现了对 Collection 的元素的成功访问 public void visitCollection(Collection collection) { Iterator iterator = collection.iterator() while (iterator.hasNext()) { Object o = iterator.next(); if (o instanceof Visitable) ((Visitable)o).accept(this); } public void visitString(String string) { System.out.println("'"+string+"'"); } 设计模式(Patterns in Java) -- http://www.jdon.com 82 public void visitFloat(Float float) { System.out.println(float.toString()+"f"); } } 在上面的visitCollection我们实现了对Collection每个元素访问,只使用了一个判断语句, 只要判断其是否可以访问. 至此,我们完成了 Visitor 模式基本架构. 使用 Visitor 模式的前提 对象群结构中(Collection) 中的对象类型很少改变,也就是说访问者的身份类型很少改变, 如上面中 Visitor 中的类型很少改变,如果需要增加新的操作,比如上例中我们在 ConcreteElement 具体实现外,还需要新的 ConcreteElement2 ConcreteElement3. 可见使用 Visitor 模式是有前提的,在两个接口 Visitor 和 Visitable 中,确保 Visitor 很少 变化,变化的是 Visitable,这样使用 Visitor 最方便. 如果 Visitor 也经常变化, 也就是说,对象群中的对象类型经常改变,一般建议是,不如在这 些对象类中逐个定义操作.但是 Java 的 Reflect 技术解决了这个问题. Reflect 技术是在运行期间动态获取对象类型和方法的一种技术,具体实现参考 Javaworld 的英文原文.
还剩81页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

zhengzheng

贡献于2014-07-07

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!