王大虎

王大虎:本书面向的读者

王大虎

热爱技术并且讨厌枯燥乏味技术文章的读者都可以看本书;

你是程序员,没问题,本书能够让你写出更加高效、优雅的代码;

你是架构师,那更好,设计模式可让你设计出健壮、稳定、高效的系统,并且自动地预防未来业务变化可能对系统带来的影响;

你是项目经理,也OK,设计模式可以让你的工期大大缩短,让你的项目团队成员快速地理解你的意图,最终的成果就是优质的项目:高可靠性、高稳定性、高效率和低维护成本。

 

 

王大虎

如何阅读本书

 

首先声明,本书中所有的例子都是用Java语言来实现的,但是你可以随手翻翻看,基本上能保证每X语句一个注释,可以说是在用咱们的母语讲解设计模式。即使你不懂Java语言,也没有关系,只要知道在Java中双斜杠(//)代表注释就足够了,况且Java如此强大和盛行,多了解一点没有坏处。类图看不懂?没关系,不影响你理解设计模式,多看看就懂了!

如果你还没有编程经验,我建议你把它当作小说来看,懂行的看门道,不懂行的看热闹,这里的热闹足够多,够你看一壶的了。你现在能看懂多少是多少,不懂没有关系,你要知道,经验不是像长青春痘一样,说长就长出来了,它是需要时间积累的,需要你用心去感受,然后才能明白为什么要如此设计。

如果你已经对编程有感觉了(至少2年开发经验),我相信你都能看懂,但能“懂”到什么程度,就很难说了,看你的水平了。但是,我可以保证,这里的设计模式都是你能看懂的,没有你看不懂的!我建议你通读这本书,然后挑门你最得意的编程语言,动手写吧!给自己制定一个计划,每天编写一段代码,不需要太多,200行足够,时不时地把设计模式融入到你的代码中。甭管是什么代码,比如你想编写一个识别美女图片的程序,好呀,抓紧时间去写吧,写好了就不用到处看美女了,程序一跑就把网上的美女图片都抓过来了,牛呀(记住,程序写好了要分享给我)。看吧,坚持下去,一年以后你再跟你的同侪比较一下,那差距肯定不是一般的大。

如果你是资深工程师、架构师、技术顾问等高等级的技术人员,那我告诉你,你找对这本书了。系统架构没有思路?没有问题,看看扩展部分,它会开阔你的思路。系统的维护成本居高不下?看看本书,设计模式也许能帮你省点银子。开发资源无法保证?设计模式能让你用有限的资源(软硬件资源和人力资源)设计出一个优秀的系统。项目质量参差不齐,缺陷一大堆?多用设计模式,它会给你意想不到的效果。给人讲课没有素材?没问题,本书中的素材足以让你赢得阵阵掌声!

编程是一门艺术活,我有一个同事,能把类图画成一个小乌龟的形状,天才呀!作为一位技术人员,最基本的品质就是诚实,“知之为知之,不知为不知,是知也”,自己不懂没有关系,去学,学无止境,但是千万不要贪多,这抓一点,那挖一点,好像什么都懂,其实什么都不懂。中国一直推崇复合型人才,我不是很赞成,因为这对年轻人来说是一个误导。先精一项技术,然后再发散学习,先点后面才是正道。

记得《武林外传》中有这样一段对话:

刑捕头:手中无刀,心中有刀。

老白:错了,最高境界是手中无刀,心中也无刀。

体验一下吧,我们的设计模式就是一把刀,极致的境界就是心中无设计模式,代码亦无设计模式——设计模式随处可见,俯拾皆是,已经融入软件设计的灵魂中,这才是高手中的高手,简称高高手。

哦,最最重要的忘记说了,请把附录中的“23种设计模式附图”撕下来,贴在你的办公桌前,时不时地看看,也让老板看看,咱是多么地用心!

王大虎

关于书名

乍一看,书名和内容貌似不相符呀,其实不然!

在我们的常规思维中,“禅”应该是很高深的东西,只可意会,不可言传。没错,禅宗也是如此说。禅是得道者的“悟”,是不能用言语来表达的,但是得道者为了能让更多的人“悟”,就必须用最容易让人理解的文字把自己的体会表达出来。本书的“禅”是作者对设计模式的“悟”,本书的“形”就是你现在看到的这些极其简单、通俗、易懂的文字。

至此,大家应该不会再对书名有疑虑了吧,嘿嘿。

本书的写作耗时7个月,可以说是榨干了海绵里所有的水——基本上能用的时间都用上了。在公交车上打腹稿,干过!在马桶上查资料,干过!在睡梦中思考案例,也有过!就差没有走火入魔了!

首先,感谢杨福川编辑,没有他的慧眼,这本书不可能出版。其次,感谢妻子和儿子,每天下班回到家,一按门铃,儿子就在里面叫:“我来开门,我来开门。”儿子三岁,太调皮了,他不睡觉我基本上是不能开写的,我一旦开始写东西,他就跑过来问:“爸爸,你在干什么呀”,紧接着下一句就是“爸爸,你陪我玩”,基本都是拿我当玩具,别的小朋友都是把父亲当马骑,他却不,他把我当摩托车骑,还要加油门,发动……小家伙脚太重了,再骑摩托,非被他踩死不可!

再次,还要感谢《Spring技术内幕——深入解析Spring架构与设计原理》的作者计文柯先生、《冒号课堂:编程范式与OOP思想》的作者X先生、《Spring揭秘》的作者X强先生、《GWT揭秘》的作者徐彬先生,他们专业、细致、耐心的审核使得本书更加完美,特别是X先生,虽言语不多,但言必中的,受益匪浅。非常X能获得他们四位的指导!

王大虎
王大虎

最后要感谢我的朋友王骢,周末只要小家伙在家,我只有找地方写书的份儿,王骢非常爽快地把钥匙给我,让我有一个安静的地方写书。一个人沉浸在自己喜欢的世界里也是一件非常幸福的事。

当然,还要感谢JavaEye上所有顶帖的网友,没有你们的支持我就失去了写作的动力,就像希腊神话中的巨人安泰失去了大地的力量一样,是你们的回帖让我觉得不孤单,让我知道我不是一个人在战斗!

最后,再次对本书中可能出现的错误表示歉意,真诚地接受大家轰炸!如果你在阅读本书时发现错误或有问题想讨论,请发邮件给我。

我的邮箱:cbf4life@126.com。

王大虎

第一部分 大旗不挥,谁敢冲锋——6大设计原则全新解读

第1章 单一职责原则

第2章 里氏替换原则

第3章 依赖倒置原则

第4章 接口隔离原则

第5章 迪米特法则

第6章 开闭原则

 

 

第1章 单一职责原则

 

1.1 我是“牛”类,我可以担任多职吗

 

单一职责原则的英文名称是Single Responsibility Principle,简称是SRP。这个设计原则备受争议,只要你想和别人争执、怄气或者是吵架,这个原则是屡试不爽的。如果你是老大,看到一个接口或类是这样或那样设计的,你就问一句:“你设计的类符合SRP原则吗?”保准对方立马“X”掉,而且还一脸崇拜地看着你,心想:“老大确实英明”。这个原则存在争议之处在哪里呢?就是对职责的定义,什么是类的职责,以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。

只要做过项目,肯定要接触到用户、机构、角色管理这些模块,基本上使用的都是RBAC模型(Role-Based Access Control,基于角色的访问控制,通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离),确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构(一个人属于多个机构)、增加角色等,用户有这么多的信息和行为要维护,我们就把这些写到一个接口中,都是用户管理类嘛,我们先来看它的类图,如图1-1所示。

 

图1-1 用户信息维护类图

太Easy的类图了,我相信,即使是一个初级的程序员也可以看出这个接口设计得有问题,用户的属性和用户的行为没有分开,这是一个严重的错误!这个接口确实设计得一团糟,应该把用户的信息抽取成一个BO(Bussiness Object,业务对象),把行为抽取成一个Biz(Business Logic,业务逻辑),按照这个思路对类图进行修正,如图1-2所示。

重新拆封成两个接口,IUserBO负责用户的属性,简单地说,IUserBO的职责就是收集和反馈用户的属性信息;IUserBiz负责用户的行为,完成用户信息的维护和变更。各位可能要说了,这个与我实际工作中用到的User类还是有差别的呀!别着急,我们先来看一看分拆成两个接口怎么使用。OK,我们现在是面向接口编程,所以产生了这个UserInfo对象之后,当然可以把它当IUserBO接口使用。也可以当IUserBiz接口使用,这要看你在什么地方使用了。要获得用户信息,就当是IUserBO的实现类;要是希望维护用户的信息,就把它当作IUserBiz的实现类就成了,如代码清单1-1所示。

 

王大虎

图1-2 职责划分后的类图

代码清单1-1 分清职责后的代码示例

确实可以如此,问题也解决了,但是我们来分析一下刚才的动作,为什么要把一个接口拆分成两个呢?其实,在实际的使用中,我们更倾向于使用两个不同的类或接口:一个是IUserBO,一个是IUserBiz,类图如图1-3所示。

 

图1-3 项目中经常采用的SRP类图

以上我们把一个接口拆分成两个接口的动作,就是依赖了单一职责原则,那什么是单一职责原则呢?单一职责原则的定义是:应该有且仅有一个原因引起类的变更。

1.2 绝杀技,打破你的传统思维

解释到这里,估计你已经很不屑了,“切!这么简单的东西还要讲?!”好,我们来讲点复杂的。SRP的原话解释是:

There should never be more than one reason for a class to change.

这句话初中生都能看懂,不多说,但是看懂是X事,实施就是另外X事了。上面讲的例子很好理解,在实际项目中大家都已经这么做了,那我们再来看看下面这个例子是否好理解。电话这玩意,是现代人都离不了,电话通话的时候有4个过程发生:拨号、通话、回应、挂机,那我们写一个接口,其类图如图1-4所示。

public interface IPhone { //拨通电话 public void dial(String phoneNumber); //通话 public void chat(Object o); //通话完毕,挂电话 public void hangup(); }

实现类也比较简单,我就不再写了,大家看看这个接口有没有问题?我相信大部分的读者都会说这个没有问题呀,以前我就是这么做的呀,某某书上也是这么写的呀,还有什么什么的源码也是这么写的!是的,这个接口接近于完美,看清楚了,是“接近”!单一职责原则要求一个接口或类只有一个原因引起变化,也就是一个接口或类只有一个职责,它就负责一件事情,看看上面的接口只负责一件事情吗?是只有一个原因引起变化吗?好像不是!

IPhone这个接口可不是只有一个职责,它包含了两个职责:一个是协议管理,一个是数据传送。dial()和hangup()两个方法实现的是协议管理,分别负责拨号接通和挂机;chat()实现的是数据的传送,把我们说的话转换成模拟信号或数字信号传递到对方,然后再把对方传递过来的信号还原成我们听得懂的语言。我们可以这样考虑这个问题,协议接通的变化会引起这个接口或实现类的变化吗?会的!那数据传送(想想看,电话不仅仅可以通话,还可以上网)的变化会引起这个接口或实现类的变化吗?会的!那就很简单了,这里有两个原因都引起了类的变化。这两个职责会相互影响吗?电话拨号,我只要能接通就成,甭管是电信的还是网通的协议;电话连接后还关心传递的是什么数据吗?通过这样的分析,我们发现类图上的IPhone接口包含了两个职责,而且这两个职责的变化不相互影响,那就考虑拆分成两个接口,其类图如图1-5所示。

这个类图看上去有点复杂了,完全满足了单一职责原则的要求,每个接口职责分明,结构清晰,但是我相信你在设计的时候肯定不会采用这种方式,一个手机类要把ConnectionManager和DataTransfer组合在一块才能使用。组合是一种强耦合关系,你和我都有共同的生命期,这样的强耦合关系还不如使用接口实现的方式呢,而且还增加了类的复杂性,多了两个类。经过这样的思考后,我们再修改一下类图,如图1-6所示。

 

王大虎

图1-5 职责分明的电话类图

 

图1-6 简洁清晰、职责分明的电话类图

这样的设计才是完美的,一个类实现了两个接口,把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化了呀,是的,但是别忘记了我们是面向接口编程,我们对外公布的是接口而不是实现类。而且,如果真要实现类的单一职责,这个就必须使用上面的组合模式了,这会引起类间耦合过重、类的数量增加等问题,人为地增加了设计的复杂性。

通过上面的例子,我们来总结一下单一职责原则有什么好处:

·类的复杂性降低,实现什么职责都有清晰明确的定义;

·可读性提高,复杂性降低,那当然可读性提高了;

·可维护性提高,可读性提高,那当然更容易维护了;

·变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。

看过电话这个例子后,是不是想反思一下了,我以前的设计是不是有点问题了?不,不是的,不要怀疑自己的技术能力,单一职责原则最难划分的就是职责。一个职责一个接口,但问题是“职责”没有一个量化的标准,一个类到底要负责那些职责?这些职责该怎么细化?细化后是否都要有一个接口或类?这些都需要从实际的项目去考虑,从功能上来说,定义一个IPhone接口也没有错,实现了电话的功能,而且设计还很简单,仅仅一个接口一个实现类,实际的项目我想大家都会这么设计。项目要考虑可变因素和不可变因素,以及相关的收益成本比率,因此设计一个IPhone接口也可能是没有错的。但是,如果纯从“学究”理论上分析就有问题了,有两个可以变化的原因放到了一个接口中,这就为以后的变化带来了风险。如果以后模拟电话升级到数字电话,我们提供的接口IPhone是不是要修改了?接口修改对其他的Invoker类是不是有很大影响?

注意 单一职责原则提出了一个编写程序的标准,用“职责”或“变化原因”来衡量接口或类设计得是否优良,但是“职责”和“变化原因”都是不可度量的,因项目而异,因环境而异。

1.3 我单纯,所以我快乐

对于接口,我们在设计的时候一定要做到单一,但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增,给维护带来非常多的麻烦,而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类,然后再使用聚合或组合的方式耦合在一起,人为制造了系统的复杂性。所以原则是死的,人是活的,这句话很有道理。

单一职责原则很难在项目中得到体现,非常难,为什么?在国内,技术人员的地位和话语权都比较低,因此在项目中需要考虑环境,考虑工作量,考虑人员的技术水平,考虑硬件的资源情况,等等,最终妥协的结果是经常违背单一职责原则。而且,我们中华文明就有很多属于混合型的产物,比如筷子,我们可以把筷子当做刀来使用,分割食物;还可以当叉使用,把食物从盘子中移动到口中。而在西方的文化中,刀就是刀,叉就是叉,你去吃西餐的时候这两样肯定都是有的,刀就是切割食物,叉就是固定食物或者移动食物,分工很明晰。这种文化的差异很难一步改造过来,但是我相信随着技术的深入,单一职责原则必然会深入到项目的设计中,而且这个原则是那么的简单,简单得不需要我们更加深入地思考,单从字面上大家都应该知道是什么意思,单一职责嘛!

单一职责适用于接口、类,同时也适用于方法,什么意思呢?一个方法尽可能做一件事情,比如一个方法修改用户密码,不要把这个方法放到“修改用户信息”方法中,这个方法的颗粒度很粗,比如图1-7中所示的方法。

 

王大虎

图1-7 一个方法承担多个职责

在IUserManager中定义了一个方法changeUser,根据传递的类型不同,把可变长度参数changeOptions修改到userBO这个对象上,并调用持久层的方法保存到数据库中。在我的项目组中,如果有人写了这样一个方法,我不管他写了多少程序,花了多少工夫,一律重写!原因很简单:方法职责不清晰,不单一,不要让别人猜测这个方法可能是用来处理什么逻辑的。比较好的设计如图1-8所示。

 

图1-8 一个方法承担一个职责

通过上面的类图,如果要修改用户名称,就调用changeUserName方法;要修改家庭地址,就调用changeHomeAddress方法;要修改单位电话,就调用changeOfficeTel方法。每个方法的职责非常清晰明确,不仅开发简单,而且日后的维护也非常容易,大家可以逐渐养成这样的习惯。

所以,如果对接口、类、方法使用了单一职责原则,那么快乐的就不仅仅是你了,还有你的项目组成员,大家可以轻松而又愉快地进行开发;还有你的老板,减少了因为变更引起的工作量,减少了无谓的人员和资金消耗。当然,最快乐的也许就是你了,因为加官进爵可能等着你哟!

1.4 最佳实践

王大虎

阅读到这里,可能有人会问我,你写的是类的设计原则吗?你通篇都在说接口的单一职责,类的单一职责你都违背了呀!呵呵,这个还真是的,我的本意是想把这个原则讲清楚,类的单一职责嘛,这个很简单,但当我回头写的时候,发觉并不是这么回事,翻看了以前的一些设计和代码,基本上拿得出手的类设计都是与单一职责相违背的。静下心来回忆,发觉每一个类这样设计都是有原因的。我查阅了Wikipedia、OODesign等几个网站,专家和我也有类似的经验,基本上类的单一职责都用了类似的一句话来说“This is sometimes hard to see”,这句话翻译过来就是“这个有时候很难说”。是的,类的单一职责确实受非常多因素的制约,纯理论地来讲,这个原则是非常优秀的,但是现实有现实的难处,你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑X政策、垄断协议等因素。比如,2004年我就做过一个项目,做加X理的,甲方就甩过来一句话,你什么都不用管,调用这个API就可以了,不用考虑什么传输协议、异常处理、安全连接等。所以,我们就直接使用了JNI与加密厂商提供的API通信,什么单一职责原则,根本就不用考虑,因为对方不公布通信接口和异常判断。

对于单一职责原则,我的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注