设计模式之禅-第2版

内容简介

本书是设计模式领域的3本经典著作之一，“趣味，容易理解，但讲解又极为严谨和透彻”是本书的写作风格和方法的特点。第1版2010年出版，至今，广受好评，是该领域的里程碑著作。深刻解读6大设计原则和28种设计模式的准确定义、应用方法和实践，比较各种同类模式之间的异同，详细讲解将不同的模式组合使用的方法。第2版在第1版的基础上有两方面的改进，一方面结合读者的意见和建议对原有内容中的瑕疵进行了修正和完善，另一方面增加了4种新的设计模式，希望这一版能为广大程序员们奉上一场更加的设计模式盛宴！
全书共38章，分为五部分：第一部分（第1～6章），以一种全新的视角对面向对象程序设计的6大原则进行了深刻解读，旨在让读者能更深刻且准确地理解这些原则，为后面的学习打下基础；第二部分（第7～29章）通过大量生动的案例讲解和分析了23种用的设计模式，并进行了扩展讲解，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分（第30～33章）对同类型和相关联的模式进行了深入分析和比较，旨在阐明各种设计模式之间的差别以及它们的理想应用场景；第四部分（第34～36章）探讨了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的效用；第五部分（第37～38章）是本书的扩展篇，先从实现的角度对MVC框架的原理进行了深入分析，然后讲解了5种新的设计模式的原理、意图和实践。本书附有一份精美的设计模式彩图，可以裁剪，便于参考。

目录

"前 言
第一部分 大旗不挥，谁敢冲
锋—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
4.3 保证接口的纯洁性 33
4.4 实践 35
第5章 迪米特法则 36
5.1 迪米特法则的定义 36
5.2 我的知识你知道得越少越好 36
5.3 实践 43
第6章 开闭原则 44
6.1 开闭原则的定义 44
6.2 开闭原则的庐山真面目 44
6.3 为什么要采用开闭原则 49
6.4 如何使用开闭原则 51
6.5 实践 55
第二部分 真实枪—23种设计模式演绎
第7章 单例模式 58
7.1 我是皇帝我独苗 58
7.2 单例模式的定义 59
7.3 单例模式的应用 60
7.3.1 单例模式的优点 60
7.3.2 单例模式的缺点 60
7.3.3 单例模式的使用场景 61
7.3.4 单例模式的注意事项 61
7.4 单例模式的扩展 62
7.5 实践 64
第8章 工厂方法模式 65
8.1 女娲造人的故事 65
8.2 工厂方法模式的定义 69
8.3 工厂方法模式的应用 70
8.3.1 工厂方法模式的优点 70
8.3.2 工厂方法模式的使用场景 71
8.4 工厂方法模式的扩展 71
8.5 实践 77
第9章 抽象工厂模式 78
9.1 女娲的失误 78
9.2 抽象工厂模式的定义 83
9.3 抽象工厂模式的应用 86
9.3.1 抽象工厂模式的优点 86
9.3.2 抽象工厂模式的缺点 86
9.3.3 抽象工厂模式的使用场景 86
9.3.4 抽象工厂模式的注意事项 86
9.4 实践 87
第10章 模板方法模式 88
10.1 辉煌工程—制造悍马 88
10.2 模板方法模式的定义 93
10.3 模板方法模式的应用 94
10.3.1 模板方法模式的优点 94
10.3.2 模板方法模式的缺点 95
10.3.3 模板方法模式的使用场景 95
10.4 模板方法模式的扩展 95
10.5 实践 99
第11章 建造者模式 100
11.1 变化是永恒的 100
11.2 建造者模式的定义 109
11.3 建造者模式的应用 111
11.3.1 建造者模式的优点 111
11.3.2 建造者模式的使用场景 111
11.3.3 建造者模式的注意事项 111
11.4 建造者模式的扩展 111
11.5 实践 112
第12章 代理模式 113
12.1 我是游戏 113
12.2 代理模式的定义 116
12.3 代理模式的应用 118
12.3.1 代理模式的优点 118
12.3.2 代理模式的使用场景 119
12.4 代理模式的扩展 119
12.4.1 普通代理 119
12.4.2 强制代理 121
12.4.3 代理是有个性的 126
12.4.4 动态代理 128
12.5 实践 134
第13章 原型模式 135
13.1 个性化电子账单 135
13.2 原型模式的定义 141
13.3 原型模式的应用 142
13.3.1 原型模式的优点 142
13.3.2 原型模式的使用场景 142
13.4 原型模式的注意事项 143
13.4.1 构造函数不会被执行 143
13.4.2 浅拷贝和深拷贝 144
13.4.3 clone与final两个冤家 146
13.5 实践 146
第14章 中介者模式 147
14.1 进销存管理是这个样子的吗 147
14.2 中介者模式的定义 156

摘要与插图

"　　大旗不挥，谁敢冲锋
　　—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;
　　userBO.setPassword(""abc"");
　　//我要执行动作了，我就认为是一个业务逻辑类
　　IUserBiz userBiz = (IUserBiz)userInfo;
　　userBiz.deleteUser();
　　......
　　确实可以如此，问题也解决了，但是我们来分析一下刚才的动作，为什么要把一个接口拆分成两个呢？其实，在实际的使用中，我们更倾向于使用两个不同的类或接口：一个是IUserBO，一个是IUserBiz，类图如图1-3所示。
　　以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一职责原则呢？单一职责原则的定义是：应该有且仅有一个原因引起类的变更。
　　1.2 绝杀技，打破你的传统思维
　　解释到这里，估计你已经很不屑了，“切！这么简单的东西还要讲？！”好，我们来讲点复杂的。SRP的原话解释是：
　　There should never be more than one reason for a cl