求索阁

     为什么写这本书？今年5月份，我在JavaEye上发了一个帖子，其中提到自己已经工作9年了，总觉得这9年不应该就这么荒废了，应该给自己这9年的工作写一个总结，总结的初稿就是这本书。

      在谈为什么写这本书之前，先抖抖自己这9年职业生涯吧。大学时我是学习机械的，当时计算机刚刚热起来，自己也喜欢玩一些新奇的东西，记得最清楚的是用VB写了一个自由落体的小程序，模拟小球从桌面掉到地板上，然后计算反弹趋势，很有成就感。于是2000年毕业时，我削尖了脑袋进入了IT行业，成为了一名真正的IT男，干着起得比鸡早、睡得比鸡晚（这个鸡怎么理解，随你了）的程序员工作，操着卖白粉的心，拿着卖白菜的钱。IT男的辛酸有谁知晓！

      坦白地来说，我的性格比较沉闷，属于典型的程序员型闷骚，比较适合做技术研究。在这9年里，项目管理做过，系统分析做过，小兵当过，团队领导人也当过，但至今我还是一个做技术的。要总结这9年技术生涯，总得写点什么吧，最好是还能对其他人有点儿用的。那写什么好呢？Spring、Struts等工具框架类的书太多太多，很难再写出花样来，经过一番思考，最后选择了一个每一位技术人员都需要掌握的、但普及程度还不是非常高的、又稍微有点难度的主题——设计模式(Design Pattern，简称DP)。

      中国人有不破不立的思维，远的如秦始皇焚书坑儒、项羽火烧阿房宫,近的如破“四旧”，为什么要破才能立呢？为什么不能持续地发展呢？正是由于有了这样的思想，于是乎能改的就改，不能改的就推翻重写，没有一个持续开发蓝图，你说这是谁的错呢？是你架构师的错，你不能持续地拥抱变化，这是一个系统最失败的地方。那怎么才能实现拥抱变化的理想呢？设计模式！

      设计模式是什么？它是一套理论，由软件界的先辈们（具体的说就是“四人帮”，The Gang of Four,包括：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）总结出的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。做软件的都知道需求是最难把握的，我们可以分析现有的需求，预测可能发生的变更，但是我们不能控制需求的变更。问题来了，既然需求的变更是不可控的，那如何拥抱变化呢？幸运的是，设计模式给了我们指导，专家们首先提出了6大设计原则，但这6大设计原则仅仅是一系列“口号”，真正付诸实施还需要有详尽的指导方法，于是23个设计模式出现了。

      设计模式已经诞生15年了，在这15年里出版了很多关于它的经典著作，相信大家都能如数家珍。但是，有这么多的书顶个屁用，工作5年了还不知道什么是策略模式、状态模式、责任链模式的程序员大有人在。不信？你找个机会去“虚心”地请教一下你的同事，看看他对设计模式有多少了解。不要告诉我要翻书才明白！设计模式不是工具，它是软件开发的哲学，它能指导你如何去设计一个优秀的架构、编写一段健壮的代码、解决一个复杂的需求。

      因为它是软件行业的经验总结，因此它具有更广泛的适应性，不管你使用什么编程语言，不管你遇到什么业务类型，设计模式都可以自由地“侵入”。

      因为它不是工具，所以它没有一个可以具体测量的标尺，完全以你自己的理解为准，你认为自己多了解它，你就有可能产生多少的优秀代码和设计。

      因为它是指导思想， 你可以在此基础上自由发挥，甚至是自己设计出一套设计模式。当然可以了!

      世界上最难的有两件事：一是让人心甘情愿地把钱掏出来给你，二是把自己的思想灌输到别人的脑子里。设计模式就属于第二种，它不是一种具体的技术，不像Struts、Spring、Hibernate等框架。一个工具用久了可以熟能生巧，就像砌墙的工人一样，长年累月地砌墙，他也知道如何把墙砌整齐，如何多快好省地干活，这是一个人的本能。我们把Struts用得很溜，把Spring用得很顺手，这非常好，但这只是一个合格的程序员应该具备的基本能力！于是我们被冠以代码工人（Code Worker）——软件行业的体力劳动者。

      如果你通晓了这23种设计模式就不同了，你可以站在一个更高的层次去赏析程序代码、软件设计、架构，完成从代码工人到架构师的蜕变（感觉有点像电视购物，极尽夸张和诱惑之能事，不过设计模式和电视购物不同，它对你只有好处，没有坏处）。注意，我说的是“通晓”，别告诉我你把23个设计模式的含义、适应性、优缺点都搞清楚了就是通晓。错了！没有工作经验的积累是不可能真正理解设计模式的，这就像大家小时候一直不明白为什么爸爸妈妈要工作而不能每天陪自己玩一样。

      据说有的大学已经开了设计模式这门课，如果仅仅是几堂课，让学生对设计模式有一个初步的了解，我觉得并无不妥，但如果是专门的一门课程，我建议取消它！因为对一个尚无项目开发经验的学生来说，理解设计模式不是一般困难，而是非常非常困难！之前没有任何的实战经验，之后也没有可以立即付诸实践的场景，这样能理解设计模式吗？

      在编写本书之前，23个设计模式我都用过，而且还算比较熟练，但是当真正要写到书中时，感觉心里没普儿了。这个定义是这样的吗？是需要用抽象类还是该用接口？为什么在这里不能抽取抽象呢？为什么在实际项目中这个模式要如此蜕化？这类小问题有时候很纠结，需要花费大量的精力和时间去分析和确认。所以，在写作的过程中我有过很多忧虑，担心书中会有太多瑕疵，这种忧虑现在仍然存在。遇到挫折的时候也气馁过，但是我坚信一句话：“开弓没有回头箭，回头既是空”，既然已经开始，就一定要圆满完成。于是在2009年即将过去的今天，终于完成了本书。

本书的特色

简单、通俗、易懂，但又不肤浅，这是本书的最大特色。自己看过的技术书还算比较多，很痛恨那种大块头的巨著，搁家里当枕头都觉得太硬。如果要是再晦涩难懂点，那根本没法看，看起来实在是太累。设计模式本本就是理论性的知识，讲解的难度比较大，但我相信这本书能够把你对设计模式的恐惧一扫而光。不信？挑几页看看先！

      我的理念是：像看小说一样阅读本书。我尽量用浅显通俗的语言讲解，尽量让你有继续看下去的欲望，尽量努力让你有兴趣进入设计模式的世界，兴趣是第一老师嘛！虽然我尽量让这本书浅显、通俗、易懂，但并不代表我的讲解就很肤浅。每个设计模式讲解完毕之后，我都附加了两个非常精华的部分：设计模式扩展和最佳实践，这是俺压箱底的技能了，为了博君一看，没招了，抖出来吧！尤为值得一提的是，本书还有设计模式PK和混编设计模式两大部分内容教你如何自如地去运用这些设计模式，这是当前所有设计模式类的图书都不具备的，连“四人帮”的那本书也不例外。

      我很讨厌技术文章中夹杂着的那些晦涩难懂的文字，特别是一堆又一堆的名词堆砌，让人看着就反胃。但是为了学习技术，为了生存，还是必须看下去。国内的技术文档，基本上都是板着一副冷面孔讲技术，为什么要把技术弄得这么生硬呢？技术也有它幽默、柔情的一面，只是被我们的“孔夫子们”掩盖了，能用萝卜、白菜这种寻常人都熟悉的知识来讲解原子弹理论的人，那是牛人，我佩服这样的人。记住，用一堆名词把你忽悠晕的人很可能什么都不懂！

      本书想告诉你的是，技术也可以很有乐趣，也可以让你不用皱着眉头思考，等待你的只是静静地看，慢慢的思考，本书的内容会润物细无声地溶入你的思维中。

本书面向的读者

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

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

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

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

如何阅读本书

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

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

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

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

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

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

      刑捕头：手中无刀，心中有刀。

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

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

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

致谢

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

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

      再次，还要感谢《Spring技术内幕》的作者计文柯先生、《冒号课堂》的作者郑晖先生、《Spring揭秘》的作者王福强先生、《GWT揭秘》的作者徐彬先生，他们专业、细致、耐心的审核使得本书更加完美，特别是郑晖老师，虽言语不多，但言必中的，受益匪浅，非常幸运能获得他们四位的指导！

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

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

      最后，再次对本书中出现的错误表示歉意，真诚地接受大家轰炸！