- 定价：￥89.00
- 校园优惠价：￥62.30 (70折) (马上了解)
- 评分：
（已有39条评价） - 电子书：设计模式之禅(第2版)
- 促销活动：
- 我要买：
基本信息
【插图】
编辑推荐
畅销书全新升级，第1版广受好评，被誉为设计模式领域最具趣味、最易理解且又讲解极为透彻的一本书，程序员公认的3本经典设计模式著作之一
深刻解读6大设计原则和28种设计模式的准确定义、应用方法和最佳实践，全方位比较各种同类模式之间的异同，详细讲解组合使用不同模式的方法
内容简介
书籍
计算机书籍
《设计模式之禅（第2版）》是设计模式领域公认的3本经典著作之一，“极具趣味，容易理解，但讲解又极为严谨和透彻”是本书的写作风格和方法的最大特点。第1版2010年出版，畅销至今，广受好评，是该领域的里程碑著作。深刻解读6大设计原则和28种设计模式的准确定义、应用方法和最佳实践，全方位比较各种同类模式之间的异同，详细讲解将不同的模式组合使用的方法。第2版在第1版的基础上有两方面的改进，一方面结合读者的意见和建议对原有内容中的瑕疵进行了修正和完善，另一方面增加了4种新的设计模式，希望这一版能为广大程序员们奉上一场更加完美的设计模式盛宴！
全书共38章，分为五部分：第一部分（第1～6章），以一种全新的视角对面向对象程序设计的6大原则进行了深刻解读，旨在让读者能更深刻且准确地理解这些原则，为后面的学习打下基础；第二部分（第7～29章）通过大量生动的案例讲解和分析了23种最常用的设计模式，并进行了扩展讲解，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分（第30～33章）对同类型和相关联的模式进行了深入分析和比较，旨在阐明各种设计模式之间的差别以及它们的理想应用场景；第四部分（第34～36章）探讨了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的最大效用；第五部分（第37～38章）是本书的扩展篇，首先从实现的角度对MVC框架的原理进行了深入分析，然后讲解了5种新的设计模式的原理、意图和最佳实践。本书最后附有一份精美的设计模式彩图，可以裁剪，便于参考。
计算机书籍
《设计模式之禅（第2版）》是设计模式领域公认的3本经典著作之一，“极具趣味，容易理解，但讲解又极为严谨和透彻”是本书的写作风格和方法的最大特点。第1版2010年出版，畅销至今，广受好评，是该领域的里程碑著作。深刻解读6大设计原则和28种设计模式的准确定义、应用方法和最佳实践，全方位比较各种同类模式之间的异同，详细讲解将不同的模式组合使用的方法。第2版在第1版的基础上有两方面的改进，一方面结合读者的意见和建议对原有内容中的瑕疵进行了修正和完善，另一方面增加了4种新的设计模式，希望这一版能为广大程序员们奉上一场更加完美的设计模式盛宴！
全书共38章，分为五部分：第一部分（第1～6章），以一种全新的视角对面向对象程序设计的6大原则进行了深刻解读，旨在让读者能更深刻且准确地理解这些原则，为后面的学习打下基础；第二部分（第7～29章）通过大量生动的案例讲解和分析了23种最常用的设计模式，并进行了扩展讲解，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分（第30～33章）对同类型和相关联的模式进行了深入分析和比较，旨在阐明各种设计模式之间的差别以及它们的理想应用场景；第四部分（第34～36章）探讨了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的最大效用；第五部分（第37～38章）是本书的扩展篇，首先从实现的角度对MVC框架的原理进行了深入分析，然后讲解了5种新的设计模式的原理、意图和最佳实践。本书最后附有一份精美的设计模式彩图，可以裁剪，便于参考。
作译者
秦小波，资深软件开发工程师、系统分析师和架构师(获Sun架构师认证)，从事软件开发工作10余年，实践经验极其丰富。精通设计模式，对设计模式有深刻的认识和独到见解，经过长期大量的实践和总结，创造性地提出新的设计模式。资深Java技术专家，精通Spring、Struts 2、Hibernate、iBatis、iBPM等Java技术，在企业级Java应用领域积累了大量经验，对基于ESB、BPEL的服务集成技术也有深入的认识。此外，还是一位优秀的DBA，具有IBM DB2 DBA资格认证，对海量数据处理有深入的研究。著有畅销书《编写高质量代码：改善Java程序的151个建议》，广受读者好评!
目录
《设计模式之禅（第2版）》
前 言
第一部分 大旗不挥，谁敢冲锋—6大设计原则全新解读
第1章 单一职责原则 2
1.1 我是“牛”类，我可以担任多职吗 2
1.2 绝杀技，打破你的传统思维 3
1.3 我单纯，所以我快乐 6
1.4 最佳实践 7
第2章 里氏替换原则 8
2.1 爱恨纠葛的父子关系 8
2.2 纠纷不断，规则压制 9
2.3 最佳实践 18
第3章 依赖倒置原则 19
3.1 依赖倒置原则的定义 19
3.2 言而无信，你太需要契约 20
3.3 依赖的三种写法 25
3.4 最佳实践 26
第4章 接口隔离原则 28
4.1 接口隔离原则的定义 28
4.2 美女何其多，观点各不同 29
前 言
第一部分 大旗不挥，谁敢冲锋—6大设计原则全新解读
第1章 单一职责原则 2
1.1 我是“牛”类，我可以担任多职吗 2
1.2 绝杀技，打破你的传统思维 3
1.3 我单纯，所以我快乐 6
1.4 最佳实践 7
第2章 里氏替换原则 8
2.1 爱恨纠葛的父子关系 8
2.2 纠纷不断，规则压制 9
2.3 最佳实践 18
第3章 依赖倒置原则 19
3.1 依赖倒置原则的定义 19
3.2 言而无信，你太需要契约 20
3.3 依赖的三种写法 25
3.4 最佳实践 26
第4章 接口隔离原则 28
4.1 接口隔离原则的定义 28
4.2 美女何其多，观点各不同 29
前言
为什么写这本书
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种设计模式我都用过，而且还算比较熟练，但是当真正要写到书中时，感觉心里没谱儿了。这个定义是这样的吗？是需要用抽象类还是应该用接口？为什么在这里不能抽取抽象呢？为什么在实际项目中这个模式要如此蜕化？这类小问题有时候很纠结，需要花费大量的精力和时间去分析和确认。所以，在写作的过程中我有过很多忧虑，担心书中会有太多瑕疵，这种忧虑现在仍然存在。遇到挫折的时候也气馁过，但是我坚信一句话：“开弓没有回头箭，回头即是空”，既然已经开始，就一定要圆满完成。
第2版与第1版的区别
本书是第2版，在写作中吸取了读者对上一版的许多意见和建议，修订了一些代码的变量、类、方法名称，以更加符合自然语言；删除了部分有争议的内容（如单例模式的垃圾回收问题）；修改了一些常用的名词，确保与编程人员的习惯相匹配。希望通过这些改进，给读者提供一个更完美的设计模式盛宴，弥补上一版中的诸多不足。
第2版第38章中新增了4种新的设计模式：对象池模式、雇工模式、黑板模式、空指针模式。这些模式是我们在实际工作中经常遇到，或者在开源代码时常看到的，但是我们却没有升级到“ 模式”这一理性高度。特别是像空指针模式，我们在编码中经常会遇到空值判断问题，但我们没有去想一想是否可以有更好的方式解决。第2版对空指针模式进行了讲解，虽然简单，但相信对你提升编码质量有很大的帮助。
本书的特色
简单、通俗、易懂，但又不肤浅，这是本书的最大特色。自己看过的技术书还算比较多，很痛恨那种大块头的巨著，搁家里当枕头都觉得太硬。如果要是再晦涩难懂点，那根本没法看，看起来实在是太累。设计模式原本就是理论性的知识，讲解的难度比较大，但我相信这本书能够把你对设计模式的恐惧一扫而光。不信？挑几页先看看！
我的理念是：像看小说一样阅读本书。我尽量用浅显通俗的语言讲解，尽量让你有继续看下去的欲望，尽量努力让你有兴趣进入设计模式的世界，兴趣是第一老师嘛！虽然我尽量让这本书浅显、通俗、易懂，但并不代表我的讲解就很肤浅。每个设计模式讲解完毕之后，我都附加了两个非常精华的部分：设计模式扩展和最佳实践，这是俺压箱底的技能了，为了博君一看，没招了，抖出来吧！尤为值得一提的是，本书还有设计模式PK和混编设计模式两部分内容教你如何自如地去运用这些设计模式，这是当前所有设计模式类的图书都不具备的，连最权威的那本书也不例外。
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种设计模式我都用过，而且还算比较熟练，但是当真正要写到书中时，感觉心里没谱儿了。这个定义是这样的吗？是需要用抽象类还是应该用接口？为什么在这里不能抽取抽象呢？为什么在实际项目中这个模式要如此蜕化？这类小问题有时候很纠结，需要花费大量的精力和时间去分析和确认。所以，在写作的过程中我有过很多忧虑，担心书中会有太多瑕疵，这种忧虑现在仍然存在。遇到挫折的时候也气馁过，但是我坚信一句话：“开弓没有回头箭，回头即是空”，既然已经开始，就一定要圆满完成。
第2版与第1版的区别
本书是第2版，在写作中吸取了读者对上一版的许多意见和建议，修订了一些代码的变量、类、方法名称，以更加符合自然语言；删除了部分有争议的内容（如单例模式的垃圾回收问题）；修改了一些常用的名词，确保与编程人员的习惯相匹配。希望通过这些改进，给读者提供一个更完美的设计模式盛宴，弥补上一版中的诸多不足。
第2版第38章中新增了4种新的设计模式：对象池模式、雇工模式、黑板模式、空指针模式。这些模式是我们在实际工作中经常遇到，或者在开源代码时常看到的，但是我们却没有升级到“ 模式”这一理性高度。特别是像空指针模式，我们在编码中经常会遇到空值判断问题，但我们没有去想一想是否可以有更好的方式解决。第2版对空指针模式进行了讲解，虽然简单，但相信对你提升编码质量有很大的帮助。
本书的特色
简单、通俗、易懂，但又不肤浅，这是本书的最大特色。自己看过的技术书还算比较多，很痛恨那种大块头的巨著，搁家里当枕头都觉得太硬。如果要是再晦涩难懂点，那根本没法看，看起来实在是太累。设计模式原本就是理论性的知识，讲解的难度比较大，但我相信这本书能够把你对设计模式的恐惧一扫而光。不信？挑几页先看看！
我的理念是：像看小说一样阅读本书。我尽量用浅显通俗的语言讲解，尽量让你有继续看下去的欲望，尽量努力让你有兴趣进入设计模式的世界，兴趣是第一老师嘛！虽然我尽量让这本书浅显、通俗、易懂，但并不代表我的讲解就很肤浅。每个设计模式讲解完毕之后，我都附加了两个非常精华的部分：设计模式扩展和最佳实践，这是俺压箱底的技能了，为了博君一看，没招了，抖出来吧！尤为值得一提的是，本书还有设计模式PK和混编设计模式两部分内容教你如何自如地去运用这些设计模式，这是当前所有设计模式类的图书都不具备的，连最权威的那本书也不例外。
书摘
大旗不挥，谁敢冲锋
—6大设计原则全新解读
第1章 单一职责原则
第2章 里氏替换原则
第3章 依赖倒置原则
第4章 接口隔离原则
第5章 迪米特法则
第6章 开闭原则 单一职责原则
1.1 我是“牛”类，我可以担任多职吗
单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。这个设计原则备受争议，只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或类是这样或那样设计的，你就问一句：“你设计的类符合SRP原则吗？”保准对方立马“萎缩”掉，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。
只要做过项目，肯定要接触到用户、机构、角色管理这些模块，基本上使用的都是RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离），确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构（一个人属于多个机构）、增加角色等，用户有这么多的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看它的类图，如图1-1所示。
太Easy的类图了，我相信，即使是一个初级的程序员也可以看出这个接口设计得有问题，用户的属性和用户的行为没有分开，这是一个严重的错误！这个接口确实设计得一团糟，应该把用户的信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑），按照这个思路对类图进行修正，如图1-2所示。
重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User类还是有差别的呀！别着急，我们先来看一看分拆成两个接口怎么使用。OK，我们现在是面向接口编程，所以产生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。也可以当IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当作IUserBiz的实现类就成了，如代码清单1-1所示。
图1-2 职责划分后的类图
代码清单1-1
分清职责后的代码示例
......
IUserInfo userInfo = new UserInfo(); //
我要赋值了，我就认为它是一个纯粹的
BO IUserBO userBO =(IUserBO)userInfo;
—6大设计原则全新解读
第1章 单一职责原则
第2章 里氏替换原则
第3章 依赖倒置原则
第4章 接口隔离原则
第5章 迪米特法则
第6章 开闭原则 单一职责原则
1.1 我是“牛”类，我可以担任多职吗
单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。这个设计原则备受争议，只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或类是这样或那样设计的，你就问一句：“你设计的类符合SRP原则吗？”保准对方立马“萎缩”掉，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。
只要做过项目，肯定要接触到用户、机构、角色管理这些模块，基本上使用的都是RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离），确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构（一个人属于多个机构）、增加角色等，用户有这么多的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看它的类图，如图1-1所示。
太Easy的类图了，我相信，即使是一个初级的程序员也可以看出这个接口设计得有问题，用户的属性和用户的行为没有分开，这是一个严重的错误！这个接口确实设计得一团糟，应该把用户的信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑），按照这个思路对类图进行修正，如图1-2所示。
重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User类还是有差别的呀！别着急，我们先来看一看分拆成两个接口怎么使用。OK，我们现在是面向接口编程，所以产生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。也可以当IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当作IUserBiz的实现类就成了，如代码清单1-1所示。
图1-2 职责划分后的类图
代码清单1-1
分清职责后的代码示例
......
IUserInfo userInfo = new UserInfo(); //
我要赋值了，我就认为它是一个纯粹的
BO IUserBO userBO =(IUserBO)userInfo;
