企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
前言 为什么写这本书 2009年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种设计模式出现了。 设计模式已经诞近20年了,其间出版了很多关于它的经典著作,相信大家都能如数家珍。尽管有这么多书,工作5年了还不知道什么是策略模式、状态模式、责任链模式的程序员大有人在。不信?你找个机会去“虚心”地请教一下你的同事,看看他对设计模式有多少了解。不要告诉我要翻书才明白!设计模式不是工具,它是软件开发的哲学,它能指导你如何去设计一个优秀的架构、编写一段健壮的代码、解决一个复杂的需求。 因为它是软件行业的经验总结,因此它具有更广泛的适应性,不管你使用什么编程语言,不管你遇到什么业务类型,设计模式都可以自由地“侵入”。 因为它不是工具,所以它没有一个可以具体测量的标尺,完全以你自己的理解为准,你认为自己多了解它,你就有可能产生多少的优秀代码和设计。 因为它是指导思想,你可以在此基础上自由发挥,甚至是自己设计出一套设计模式。 世界上最难的事有两件:一是让人心甘情愿地把钱掏出来给你,二是把自己的思想灌输到别人的脑子里。设计模式就属于第二种,它不是一种具体的技术,不像Struts、Spring、Hibernate等框架。一个工具用久了可以熟能生巧,就像砌墙的工人一样,长年累月地砌墙,他也知道如何把墙砌整齐,如何多快好省地干活,这是一个人的本能。我们把Struts用得很溜,把Spring用得很顺手,这非常好,但这只是一个合格的程序员应该具备的基本能力!于是我们被冠以代码工人(Code Worker)——软件行业的体力劳动者。 如果你通晓了这23种设计模式就不同了,你可以站在一个更高的层次去赏析程序代码、软件设计、架构,完成从代码工人到架构师的蜕变。注意,我说的是“通晓”,别告诉我你把23种设计模式的含义、适应性、优缺点都搞清楚了就是通晓。错了!没有工作经验的积累是不可能真正理解设计模式的,这就像大家小时候一直不明白为什么爸爸妈妈要工作而不能每天陪自己玩一样。 据说有的大学已经开了设计模式这门课,如果仅仅是几堂课,让学生对设计模式有一个初步的了解,我觉得并无不妥,但如果是专门的一门课程,我建议取消它!因为对一个尚无项目开发经验的学生来说,理解设计模式不是一般困难,而是非常非常困难!之前没有任何的实战经验,之后也没有可以立即付诸实践的场景,这样能理解设计模式吗? 在编写本书之前,23种设计模式我都用过,而且还算比较熟练,但是当真正要写到书中时,感觉心里没谱儿了。这个定义是这样的吗?是需要用抽象类还是应该用接口?为什么在这里不能抽取抽象呢?为什么在实际项目中这个模式要如此蜕化?这类小问题有时候很纠结,需要花费大量的精力和时间去分析和确认。所以,在写作的过程中我有过很多忧虑,担心书中会有太多瑕疵,这种忧虑现在仍然存在。遇到挫折的时候也气馁过,但是我坚信一句话:“开弓没有回头箭,回头即是空”,既然已经开始,就一定要圆满完成。