设计模式之禅(Java版) (china-pub首发)(版权输出至台湾)
点击看大图基本信息
- 原书名：The Zen of Design Patterns
- 作者： 秦小波
- 丛书名： 华章原创精品
- 出版社：机械工业出版社
- ISBN：9787111295440
- 上架时间：2010-3-23
- 出版日期：2010 年3月
- 开本：16开
- 页码：545
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 设计模式
编辑推荐
继GOF《设计模式》之后的又一里程碑之作！
6大原则，23+1种设计模式
设计模式PK、设计模式混编、设计模式最佳实践
推荐阅读
内容简介回到顶部↑
如果说“四人帮”的《设计模式》是设计模式领域的“圣经”，那么之后出版的各种关于设计模式的书都可称之为“圣经”的“注释版”或“圣经的故事”。本书是得道者对“圣经”的“禅悟”，它既不像“圣经”那样因为惜字如金、字字珠玑而深奥、晦涩和难懂，又比“圣经”的“注释版”更深刻和全面、更通俗和生动、更接近开发者遇到的实践场景，更具指导性。本书兼收并蓄、博采众长，也许是设计模式领域里的下一个里程碑之作。
全书共分为四部分，第一部分从原理的角度阐述了面向对象程序设计的6大原则；第二部生动地讲解和剖析了23种常见的设计模式，并进行了扩展，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分对各种相关联的设计模式进行了深入分析和比较，旨在阐明各种设计模式比较理想的应用场景和它们之间的区别；第四部分探讨了设计模式的混编，讲解了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的最大效用。最后，本书还附有一份设计模式彩图，可以裁剪，便于参考。
禅宗曰：“教外别传，不立文字”，禅的境界本不该用文字来描述，言语也道不明白，但为了传道，悟道者仍要藉言语来说明。
何为禅？一种境界，一种体验，一种精神领域的最高修为。何为设计模式？对面向对象思想的深刻理解，对软件设计方法和编码经验的完美总结。
本书是创造者的心路历程，是实践者的智慧结晶，是得道者的禅悟。它通过幽默风趣的故事和通俗易懂的讲述方式，引导你悟透设计模式的真谛。
如果你在思考下面这些问题，也许本书就是你想要的！
1. 业务分析如此细致，架构设计如此健壮、可靠和稳定，但为何仍然无法适应业务发展的需要，而且生命周期只有短短几年？
2. 为何你的团队协作了多年却始终无法沉淀出可复用的组件或构件？依赖和解耦的标准是什么？如何才能做到既不相互“刺伤”，又能相互“温暖”？
3. 架构设计时，如何才能实现高可扩展性和易维护性？如何避免维护成本大于开发成本的悲哀现状？
4. 交易型的系统如何大规模地借用设计模式的思想，以实现高性能、高可靠性的建设目标？
5. 架构设计时，如果遇到这样的情况：“有一个请求者和多个处理者，同时要求二者之间解耦，以便处理者可以动态地扩展”，这该如何处理？
6. 如果遇到过这样场景：“多个对象依赖一个对象，该对象状态改变时所有的依赖者都要相应地获得通知，并且要求对象间松散耦合”，这该如何处理？
7. 万物皆对象，不可能把每一个对象都分解到原子级别，如何适度地细化对象的颗粒度？怎样界定对象的粒度大小？
8. 同为创建类模式，工厂方法模式和建造者模式都可以创建对象，它们之间有何区别？适用的场景又有何不同？
9. 状态模式和策略模式的通用类图如此相似，在实际的应用场景中如何区分它们？
10. 如何使命令模式和责任链模式完美搭配并建立一个高可扩展性的系统架构，以解决客户端和处理者都参数化的场景？
11. 观察者模式和责任链模式真的没有可比性吗？它们的主要区别何在？实际应用中如何使用？
12. 组合模式只能用来表示部分和整体的关系吗？其扩展出的规格模式是如何实现的？透明的组合模式和安全的组合模式有何区别？
全书共分为四部分，第一部分从原理的角度阐述了面向对象程序设计的6大原则；第二部生动地讲解和剖析了23种常见的设计模式，并进行了扩展，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分对各种相关联的设计模式进行了深入分析和比较，旨在阐明各种设计模式比较理想的应用场景和它们之间的区别；第四部分探讨了设计模式的混编，讲解了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的最大效用。最后，本书还附有一份设计模式彩图，可以裁剪，便于参考。
禅宗曰：“教外别传，不立文字”，禅的境界本不该用文字来描述，言语也道不明白，但为了传道，悟道者仍要藉言语来说明。
何为禅？一种境界，一种体验，一种精神领域的最高修为。何为设计模式？对面向对象思想的深刻理解，对软件设计方法和编码经验的完美总结。
本书是创造者的心路历程，是实践者的智慧结晶，是得道者的禅悟。它通过幽默风趣的故事和通俗易懂的讲述方式，引导你悟透设计模式的真谛。
如果你在思考下面这些问题，也许本书就是你想要的！
1. 业务分析如此细致，架构设计如此健壮、可靠和稳定，但为何仍然无法适应业务发展的需要，而且生命周期只有短短几年？
2. 为何你的团队协作了多年却始终无法沉淀出可复用的组件或构件？依赖和解耦的标准是什么？如何才能做到既不相互“刺伤”，又能相互“温暖”？
3. 架构设计时，如何才能实现高可扩展性和易维护性？如何避免维护成本大于开发成本的悲哀现状？
4. 交易型的系统如何大规模地借用设计模式的思想，以实现高性能、高可靠性的建设目标？
5. 架构设计时，如果遇到这样的情况：“有一个请求者和多个处理者，同时要求二者之间解耦，以便处理者可以动态地扩展”，这该如何处理？
6. 如果遇到过这样场景：“多个对象依赖一个对象，该对象状态改变时所有的依赖者都要相应地获得通知，并且要求对象间松散耦合”，这该如何处理？
7. 万物皆对象，不可能把每一个对象都分解到原子级别，如何适度地细化对象的颗粒度？怎样界定对象的粒度大小？
8. 同为创建类模式，工厂方法模式和建造者模式都可以创建对象，它们之间有何区别？适用的场景又有何不同？
9. 状态模式和策略模式的通用类图如此相似，在实际的应用场景中如何区分它们？
10. 如何使命令模式和责任链模式完美搭配并建立一个高可扩展性的系统架构，以解决客户端和处理者都参数化的场景？
11. 观察者模式和责任链模式真的没有可比性吗？它们的主要区别何在？实际应用中如何使用？
12. 组合模式只能用来表示部分和整体的关系吗？其扩展出的规格模式是如何实现的？透明的组合模式和安全的组合模式有何区别？
作译者回到顶部↑
目录回到顶部↑
前 言
第一部分 大旗不挥，谁敢
冲锋—热身篇
第1章 单一职责原则
1.1 我是“牛”类，我可以担任多职吗
1.2 绝杀技，打破你的传统思维
1.3 我单纯，所以我快乐
1.4 最佳实践
第2章 里氏替换原则
2.1 爱恨纠葛的父子关系
2.2 纠纷不断，规则压制
2.3 最佳实践
第3章 依赖倒置原则
3.1 依赖倒置原则的定义
3.2 言而无信，你太需要契约
3.3 依赖的三种写法
3.4 最佳实践
第4章 接口隔离原则
4.1 接口隔离原则的定义
4.2 美女何其多，观点各不同
第一部分 大旗不挥，谁敢
冲锋—热身篇
第1章 单一职责原则
1.1 我是“牛”类，我可以担任多职吗
1.2 绝杀技，打破你的传统思维
1.3 我单纯，所以我快乐
1.4 最佳实践
第2章 里氏替换原则
2.1 爱恨纠葛的父子关系
2.2 纠纷不断，规则压制
2.3 最佳实践
第3章 依赖倒置原则
3.1 依赖倒置原则的定义
3.2 言而无信，你太需要契约
3.3 依赖的三种写法
3.4 最佳实践
第4章 接口隔离原则
4.1 接口隔离原则的定义
4.2 美女何其多，观点各不同
前言回到顶部↑
终于可以写前言了，这说明本书已经基本完成，可以长嘘一口气了。
为什么写这本书
今年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种设计模式我都用过，而且还算比较熟练，但是当真正要写到书中时，感觉心里没谱儿了。这个定义是这样的吗？是需要用抽象类还是应该用接口？为什么在这里不能抽取抽象呢？为什么在实际项目中这个模式要如此蜕化？这类小问题有时候很纠结，需要花费大量的精力和时间去分析和确认。所以，在写作的过程中我有过很多忧虑，担心书中会有太多瑕疵，这种忧虑现在仍然存在。遇到挫折的时候也气馁过，但是我坚信一句话：“开弓没有回头箭，回头即是空”，既然已经开始，就一定要圆满完成。
本书的特色
为什么写这本书
今年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种设计模式我都用过，而且还算比较熟练，但是当真正要写到书中时，感觉心里没谱儿了。这个定义是这样的吗？是需要用抽象类还是应该用接口？为什么在这里不能抽取抽象呢？为什么在实际项目中这个模式要如此蜕化？这类小问题有时候很纠结，需要花费大量的精力和时间去分析和确认。所以，在写作的过程中我有过很多忧虑，担心书中会有太多瑕疵，这种忧虑现在仍然存在。遇到挫折的时候也气馁过，但是我坚信一句话：“开弓没有回头箭，回头即是空”，既然已经开始，就一定要圆满完成。
本书的特色
媒体评论回到顶部↑
“禅”是一种境界，是得道者的智慧结晶。本书在写作方式上别出心裁，不是将设计模式的概念强行灌输给读者，而是以浅显的故事作为衬垫，深入浅出地展示了设计模式中蕴涵的哲理，进而引发读者的思考，提升他们的实际开发水平。
——51CTO读书频道（http://book.51cto.com/）
聪明的人，把房子盖在磐石上；无知的人，把房子盖在沙土上。对于开发者而言，设计模式就是那坚固的磐石。本书是设计模式领域难得一见的佳作，它用一种创新的方式对面向对象的设计原则和设计模式的要义进行了全新的阐释。对于所有Java开发者而言，无论你是初窥门径，还是深谙其道，本书都值得你阅读并收藏。
—Java开发者社区
本书不仅从开发者的角度对设计模式进行了独到而具有创意性的讲解，而且还从架构师的角度深刻地分析了设计模式在软件架构中的重要性。设计模式是架构师必备的的技能之一，它的思想和原则能指导架构师设计出更优秀的软件架构。强烈推荐所有架构师阅读本书。
—架构师社区
多年前学设计模式，犯困无数次，打盹若干回。程序员一直被幽默着，现在终于可以反幽默一回了。这是一本厚积薄发的书，作者以其丰富的实践经验和通俗的讲解方式，把难懂的设计模式“化为”橡皮泥，让程序员想怎么玩就怎么玩，以致读完全书，仍觉意犹未尽。
—江伍开，知名外企资深架构师，51CTO博客之星（http://wakan.blog.51cto.com/）
很多初学者都抱怨设计模式的抽象和深奥，对于他们来说，本书的出版不啻是一种福音！作者利用诙谐的语言和生动的叙述方式，结合当前国内读者熟知和易于理解的故事和开发场景，对设计模式进行了独特而全面的阐述，大大降低了设计模式的学习曲线，实在不可多得！
—计文柯，资深软件开发专家和项目经理，《Spring技术内幕—深入解析Spring架构和设计原理》作者
本书以设计模式为主题，是作者多年软件开发经验的总结。它介绍了一些重要的设计原则，并对各种经典的设计模式进行了详细的分析、比较和综合。全书通俗易懂、实例丰富，对想要学习设计模式的程序员有很大的启发和帮助。
—郑晖，资深软件开发专家和CTO，《冒号课堂》作者
无论是在建筑领域，还是在面向对象软件开发领域，如何强调设计模式的重要性都不过分。如果你觉得设计模式难学，推荐你认真阅读这本书，它用大量生动、有趣的故事将设计模式的深奥、晦涩化解于无形；如果你对设计模式一知半解，或只能“纸上谈兵”，建议你反复阅读这本书，它对面向对象的原则、设计模式的内涵和外延，以及设计模式的应用场景做了全面而深刻地阐述。
—王福强，资深软件开发专家和架构师，《Spring揭秘》作者
——51CTO读书频道（http://book.51cto.com/）
聪明的人，把房子盖在磐石上；无知的人，把房子盖在沙土上。对于开发者而言，设计模式就是那坚固的磐石。本书是设计模式领域难得一见的佳作，它用一种创新的方式对面向对象的设计原则和设计模式的要义进行了全新的阐释。对于所有Java开发者而言，无论你是初窥门径，还是深谙其道，本书都值得你阅读并收藏。
—Java开发者社区
本书不仅从开发者的角度对设计模式进行了独到而具有创意性的讲解，而且还从架构师的角度深刻地分析了设计模式在软件架构中的重要性。设计模式是架构师必备的的技能之一，它的思想和原则能指导架构师设计出更优秀的软件架构。强烈推荐所有架构师阅读本书。
—架构师社区
多年前学设计模式，犯困无数次，打盹若干回。程序员一直被幽默着，现在终于可以反幽默一回了。这是一本厚积薄发的书，作者以其丰富的实践经验和通俗的讲解方式，把难懂的设计模式“化为”橡皮泥，让程序员想怎么玩就怎么玩，以致读完全书，仍觉意犹未尽。
—江伍开，知名外企资深架构师，51CTO博客之星（http://wakan.blog.51cto.com/）
很多初学者都抱怨设计模式的抽象和深奥，对于他们来说，本书的出版不啻是一种福音！作者利用诙谐的语言和生动的叙述方式，结合当前国内读者熟知和易于理解的故事和开发场景，对设计模式进行了独特而全面的阐述，大大降低了设计模式的学习曲线，实在不可多得！
—计文柯，资深软件开发专家和项目经理，《Spring技术内幕—深入解析Spring架构和设计原理》作者
本书以设计模式为主题，是作者多年软件开发经验的总结。它介绍了一些重要的设计原则，并对各种经典的设计模式进行了详细的分析、比较和综合。全书通俗易懂、实例丰富，对想要学习设计模式的程序员有很大的启发和帮助。
—郑晖，资深软件开发专家和CTO，《冒号课堂》作者
无论是在建筑领域，还是在面向对象软件开发领域，如何强调设计模式的重要性都不过分。如果你觉得设计模式难学，推荐你认真阅读这本书，它用大量生动、有趣的故事将设计模式的深奥、晦涩化解于无形；如果你对设计模式一知半解，或只能“纸上谈兵”，建议你反复阅读这本书，它对面向对象的原则、设计模式的内涵和外延，以及设计模式的应用场景做了全面而深刻地阐述。
—王福强，资深软件开发专家和架构师，《Spring揭秘》作者
【插图】
)
加载中...
