驰华图书专营店
扫码下单

超级新品 8062258|正版Java设计模式及实践+设计模式之第2版2册套装Java核心技术系列Java语言架构师微服务面向

本店赠品为友情配送,不已赠品缺少申请售后、退款,请顾客熟知!

  • 作者: 卡马尔米特·辛格(Kamalmeet Singh)著
  • 出版社: 机械工业出版社
  • 出版时间:2019 年6月
送至
由""直接销售和发货,并提供售后服务 联系客服
加入购物车 购买电子书
服务
企业采购 针对企业客户采购的专业服务

看了又看

商品预定流程:

查看大图
/
×

驰华图书专营店

店铺装修中

商家:
驰华图书专营店
联系:
联系客服
电话:

15801409580

  • 商品

  • 服务

  • 物流

搜索店内商品

商品分类

为您推荐大家关注的

商品参数
  • 作者: 卡马尔米特·辛格(Kamalmeet Singh)著
  • 出版社:机械工业出版社
  • 出版时间:2019 年6月
  • ISBN:9787111629436
  • 版权提供:机械工业出版社
 
.
....名: .[套装书]java设计模式及实践+设计模式之禅(第2版)(2册)
.图书定价: .168元
..者: .[印度]卡马尔米特·辛格(Kamalmeet Singh) [荷兰]艾德里安·伊恩库列斯库(Adrian Ianculescu) [罗马尼亚]路西安-保罗·托尔耶(Lucian-Paul Torje)秦小波
...社: .机械工业出版社
.出版日期: .2019-06-18
.ISBN.号: .9787111629436
....本: 16开
....数: 773
....次: 1-1

---------------------------设计模式之禅(第2版)---------------------------
秦小波,软件开发工程师、系统分析师和架构师(获Sun架构师认证),从事软件开发工作10余年,实践经验极其丰富。精通设计模式,对设计模式有深刻的认识和独到见解,经过长期大量的实践和总结,创造性地提出新的设计模式。Java技术专家,精通Spring、Struts 2、Hibernate、iBatis、iBPM等Java技术,在企业级Java应用领域积累了大量经验,对基于ESB、BPEL的服务集成技术也有深入的认识。此外,还是一位的DBA,具有IBM DB2 DBA资格认证,对海量数据处理有深入的研究。著有畅销书《编写高质量代码:改善Java程序的151个建议》,广受读者!

---------------------------Java设计模式及实践---------------------------
本书向读者展示Java语言中更加智能化的编码实例。书中首先介绍面向对象编程(OOP)和函数式编程(FP)范式,然后描述常用设计模式的经典使用方法,并解释如何利用函数式编程特性改变经典的设计模式。读者将学习混合使用OOP和FP的实现方式,然后学习响应式编程模型——一种为了编写更好的代码而将OOP和FP结合使用的方法。之后,本书将介绍从MVC架构向微服务和无服务器架构转变的发展趋势,最后介绍Java新版本的功能特性及其实践。通过本书的学习,读者可以有效地解决开发应用程序过程中的常见问题,能够轻松地应对各种规模项目的扩展和维护。

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




---------------------------Java设计模式及实践---------------------------


译者序
前言
关于作者
关于评审者
第1章 从面向对象到函数式编程 1
1.1 Java简介 1
1.2 Java编程范式 2
1.2.1 命令式编程 2
1.2.2 面向对象编程 3
1.2.3 声明式编程 6
1.2.4 函数式编程 6
1.3 流以及集合的使用 7
1.4 统一建模语言简介 8
1.5 设计模式和原则 11
1.5.1 单一职责原则 12
1.5.2 开闭原则 13
1.5.3 里氏替换原则 13
1.5.4 接口隔离原则 14
1.5.5 依赖倒置原则 16
1.6 总结 16
第2章 创建型模式 18
2.1 单例模式 18
2.1.1 同步锁单例模式 19
2.1.2 拥有双重校验锁机制的同步锁单例模式 20
2.1.3 无锁的线程安全单例模式 21
2.1.4 提前加载和延迟加载 21
2.2 工厂模式 22
2.2.1 简单工厂模式 22
2.2.2 工厂方法模式 25
2.2.3 抽象工厂模式 27
2.2.4 简单工厂、工厂方法与抽象工厂模式之间的对比 28
2.3 建造者模式 29
2.3.1 汽车建造者样例 30
2.3.2 简化的建造者模式 32
2.3.3 拥有方法链的匿名建造者 32
2.4 原型模式 33
2.5 对象池模式 34
2.6 总结 36
第3章 行为型模式 37
3.1 责任链模式 38
3.2 命令模式 40
3.3 解释器模式 43
3.4 迭代器模式 47
3.5 观察者模式 50
3.6 中介者模式 51
3.7 备忘录模式 53
3.8 状态模式 55
3.9 策略模式 55
3.10 模板方法模式 56
3.11 空对象模式 57
3.12 访问者模式 58
3.13 总结 59
第4章 结构型模式 60
4.1 适配器模式 61
4.2 代理模式 66
4.3 装饰器模式 70
4.4 桥接模式 73
4.5 组合模式 76
4.6 外观模式 79
4.7 享元模式 83
4.8 总结 88
第5章 函数式编程 89
5.1 函数式编程简介 89
5.1.1 lambda表达式 91
5.1.2 纯函数 92
5.1.3 引用透明性 92
5.1.4 初等函数 93
5.1.5 高阶函数 93
5.1.6 组合 93
5.1.7 柯里化 93
5.1.8 闭包 94
5.1.9 不可变性 95
5.1.10 函子 95
5.1.11 单子 96
5.2 Java中的函数式编程 97
5.2.1 lambda表达式 97
5.2.2 流 98
5.3 重新实现面向对象编程设计模式 102
5.3.1 单例模式 102
5.3.2 建造者模式 102
5.3.3 适配器模式 103
5.3.4 装饰器模式 103
5.3.5 责任链模式 103
5.3.6 命令模式 104
5.3.7 解释器模式 104
5.3.8 迭代器模式 104
5.3.9 观察者模式 105
5.3.10 策略模式 105
5.3.11 模板方法模式 105
5.4 函数式设计模式 106
5.4.1 MapReduce 106
5.4.2 借贷模式 107
5.4.3 尾调用优化 108
5.4.4 记忆化 109
5.4.5 执行around方法 110
5.5 总结 111
第6章 响应式编程 112
6.1 什么是响应式编程 113
6.2 RxJava简介 114
6.3 安装RxJava 115
6.3.1 Maven下的安装 115
6.3.2 JShell下的安装 116
6.4 Observable、Flowable、Observer和Subscription的含义 116
6.5 创建Observable 118
6.5.1 create操作符 118
6.5.2 defer操作符 119
6.5.3 empty操作符 120
6.5.4 from操作符 120
6.5.5 interval操作符 120
6.5.6 timer操作符 121
6.5.7 range操作符 121
6.5.8 repeat操作符 121
6.6 转换Observable 122
6.6.1 subscribe操作符 122
6.6.2 buffer操作符 122
6.6.3 flatMap操作符 122
6.6.4 groupBy操作符 124
6.6.5 map操作符 124
6.6.6 scan操作符 125
6.6.7 window操作符 125
6.7 过滤Observable 125
6.7.1 debounce操作符 125
6.7.2 distinct操作符 126
6.7.3 elementAt操作符 126
6.7.4 filter操作符 127
6.7.5 first/last操作符 127
6.7.6 sample操作符 128
6.7.7 skip操作符 128
6.7.8 take操作符 128
6.8 组合Observable 128
6.8.1 combine操作符 129
6.8.2 join操作符 129
6.8.3 merge操作符 130
6.8.4 zip操作符 131
6.9 异常处理 131
6.9.1 catch操作符 131
6.9.2 do操作符 132
6.9.3 using操作符 133
6.9.4 retry操作符 133
6.10 线程调度器 134
6.11 Subject 135
6.12 示例项目 136
6.13 总结 139
第7章 响应式设计模式 140
7.1 响应模式 140
7.1.1 请求-响应模式 140
7.1.2 异步通信模式 146
7.1.3 缓存模式 148
7.1.4 扇出与最快响应模式 149
7.1.5 快速失败模式 150
7.2 弹性模式 150
7.2.1 断路器模式 150
7.2.2 故障处理模式 151
7.2.3 有限队列模式 151
7.2.4 监控模式 152
7.2.5 舱壁模式 152
7.3 柔性模式 152
7.3.1 单一职责模式 153
7.3.2 无状态服务模式 154
7.3.3 自动伸缩模式 156
7.3.4 自包含模式 156
7.4 消息驱动通信模式 157
7.4.1 事件驱动通信模式 157
7.4.2 出版者-订阅者模式 157
7.4.3 幂等性模式 158
7.5 总结 158
第8章 应用架构的发展趋势 159
8.1 什么是应用架构 159
8.2 分层架构 160
8.2.1 分层架构示例 162
8.2.2 tier和layer的区别 165
8.2.3 分层架构的作用 165
8.2.4 分层架构面临的挑战 165
8.3 MVC架构 166
8.3.1 MVC架构示例 168
8.3.2 更现代的MVC实现 170
8.3.3 MVC架构的作用 171
8.3.4 MVC架构面临的挑战 171
8.4 面向服务架构 171
8.4.1 面向服务架构示例 172
8.4.2 Web服务 173
8.4.3 SOAP与REST 173
8.4.4 企业服务总线 174
8.4.5 面向服务架构的作用 174
8.4.6 面向服务架构面临的挑战 175
8.5 微服务架构 176
8.5.1 微服务架构示例 176
8.5.2 服务间的通信 178
8.5.3 微服务架构的作用 178
8.5.4 微服务架构面临的挑战 178
8.6 无服务器架构 179
8.6.1 无服务器架构示例 179
8.6.2 独立于基础设施规划 184
8.6.3 无服务器架构的作用 184
8.6.4 无服务器架构面临的挑战 184
8.7 总结 185
第9章 Java中的实践 186
9.1 Java简史 186
9.1.1 Java 5的特性 187
9.1.2 Java 8的特性 188
9.1.3 目前官方支持的Java版本 188
9.2 Java 9的实践和新特性 189
9.2.1 Java平台模块化系统 189
9.2.2 JShell 192
9.2.3 接口中的私有方法 194
9.2.4 流的增强功能 195
9.2.5 创建不可变集合 196
9.2.6 在数组中添加方法 197
9.2.7 Optional类的增强功能 198
9.2.8 新的HTTP客户端 199
9.2.9 Java 9增加的其他功能 200
9.3 Java 10的实践和新特性 201
9.3.1 局部变量类型推断 201
9.3.2 集合的copyOf方法 203
9.3.3 并行垃圾回收机制 204
9.3.4 Java 10增加的其他功能 205
9.4 总结 205



---------------------------设计模式之禅(第2版)---------------------------


《设计模式之禅(第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
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
14.3 中介者模式的应用 159
14.3.1 中介者模式的优点 159
14.3.2 中介者模式的缺点 159
14.3.3 中介者模式的使用场景 159
14.4 中介者模式的实际应用 160
14.5 实践 161
第15章 命令模式 162
15.1 项目经理也难当 162
15.2 命令模式的定义 170
15.3 命令模式的应用 173
15.3.1 命令模式的优点 173
15.3.2 命令模式的缺点 173
15.3.3 命令模式的使用场景 173
15.4 命令模式的扩展 173
15.4.1 未讲完的故事 173
15.4.2 反悔问题 174
15.5 实践 175
第16章 责任链模式 178
16.1 古代妇女的枷锁—“三从四德” 178
16.2 责任链模式的定义 186
16.3 责任链模式的应用 189
16.3.1 责任链模式的优点 189
16.3.2 责任链模式的缺点 190
16.3.3 责任链模式的注意事项 190
16.4 实践 190
第17章 装饰模式 192
17.1 罪恶的成绩单 192
17.2 装饰模式的定义 198
17.3 装饰模式应用 201
17.3.1 装饰模式的优点 201
17.3.2 装饰模式的缺点 201
17.3.3 装饰模式的使用场景 201
17.4 实践 201
第18章 策略模式 203
18.1 刘备江东娶妻,赵云他容易吗 203
18.2 策略模式的定义 206
18.3 策略模式的应用 208
18.3.1 策略模式的优点 208
18.3.2 策略模式的缺点 208
18.3.3 策略模式的使用场景 209
18.3.4 策略模式的注意事项 209
18.4 策略模式的扩展 209
18.5 实践 214
第19章 适配器模式 215
19.1 业务发展—上帝才能控制 215
19.2 适配器模式的定义 221
19.3 适配器模式的应用 223
19.3.1 适配器模式的优点 223
19.3.2 适配器模式的使用场景 224
19.3.3 适配器模式的注意事项 224
19.4 适配器模式的扩展 224
19.5 实践 229
第20章 迭代器模式 230
20.1 整理项目信息—苦差事 230
20.2 迭代器模式的定义 236
20.3 迭代器模式的应用 239
20.4 实践 239
第21章 组合模式 240
21.1 公司的人事架构是这样的吗 240
21.2 组合模式的定义 253
21.3 组合模式的应用 255
21.3.1 组合模式的优点 255
21.3.2 组合模式的缺点 256
21.3.3 组合模式的使用场景 256
21.3.4 组合模式的注意事项 256
21.4 组合模式的扩展 256
21.4.1 真实的组合模式 256
21.4.2 透明的组合模式 257
21.4.3 组合模式的遍历 259
21.5 实践 260
第22章 观察者模式 262
22.1 韩非子身边的卧底是谁派来的 262
22.2 观察者模式的定义 271
22.3 观察者模式的应用 273
22.3.1 观察者模式的优点 273
22.3.2 观察者模式的缺点 274
22.3.3 观察者模式的使用场景 274
22.3.4 观察者模式的注意事项 274
22.4 观察者模式的扩展 275
22.4.1 Java世界中的观察者模式 275
22.4.2 项目中真实的观察者模式 276
22.4.3 订阅发布模型 277
22.5 实践 277
第23章 面模式 278
23.1 我要投递信件 278
23.2 面模式的定义 283
23.3 面模式的应用 284
23.3.1 面模式的优点 284
23.3.2 面模式的缺点 285
23.3.3 面模式的使用场景 285
23.4 面模式的注意事项 285
23.4.1 一个子系统可以有多个面 285
23.4.2 面不参与子系统内的业务逻辑 286
23.5 实践 288
第24章 备忘录模式 289
24.1 如此追女孩子,你还不乐 289
24.2 备忘录模式的定义 294
24.3 备忘录模式的应用 297
24.3.1 备忘录模式的使用场景 297
24.3.2 备忘录模式的注意事项 297
24.4 备忘录模式的扩展 297
24.4.1 clone方式的备忘录 297
24.4.2 多状态的备忘录模式 300
24.4.3 多备份的备忘录 304
24.4.4 封装得更好一点 305
24.5 实践 307
第25章 访问者模式 308
25.1 员工的隐私何在 308
25.2 访问者模式的定义 316
25.3 访问者模式的应用 320
25.3.1 访问者模式的优点 320
25.3.2 访问者模式的缺点 320
25.3.3 访问者模式的使用场景 320
25.4 访问者模式的扩展 321
25.4.1 统计功能 321
25.4.2 多个访问者 323
25.4.3 双分派 326
25.5 实践 328
第26章 状态模式 329
26.1 城市的纵向发展功臣—电梯 329
26.2 状态模式的定义 341
26.3 状态模式的应用 343
26.3.1 状态模式的优点 343
26.3.2 状态模式的缺点 344
26.3.3 状态模式的使用场景 344
26.3.4 状态模式的注意事项 344
26.4 实践 344
第27章 解释器模式 346
27.1 四则运算你会吗 346
27.2 解释器模式的定义 352
27.3 解释器模式的应用 354
27.3.1 解释器模式的优点 354
27.3.2 解释器模式的缺点 354
27.3.3 解释器模式使用的场景 355
27.3.4 解释器模式的注意事项 355
27.4 实践 355
第28章 享元模式 356
28.1 内存溢出,司空见惯 356
28.2 享元模式的定义 361
28.3 享元模式的应用 364
28.3.1 享元模式的优点和缺点 364
28.3.2 享元模式的使用场景 364
28.4 享元模式的扩展 365
28.4.1 线程安全的问题 365
28.4.2 性能平衡 366
28.5 实践 369
第29章 桥梁模式 371
29.1 我有一个梦想 371
29.2 桥梁模式的定义 379
29.3 桥梁模式的应用 381
29.3.1 桥梁模式的优点 381
29.3.2 桥梁模式的使用场景 382
29.3.3 桥梁模式的注意事项 382
29.4 实践 382
第三部分 谁的地盘谁做主—设计模式PK
第30章 创建类模式大PK 384
30.1 工厂方法模式VS建造者模式 384
30.1.1 按工厂方法建造超人 384
30.1.2 按建造者模式建造超人 386
30.1.3 实践 389
30.2 抽象工厂模式VS建造者模式 390
30.2.1 按抽象工厂模式生产车辆 390
30.2.2 按建造者模式生产车辆 394
30.2.3 实践 399
第31章 结构类模式大PK 400
31.1 代理模式VS装饰模式 400
31.1.1 代理模式 400
31.1.2 装饰模式 402
31.1.3 实践 403
31.2 装饰模式VS适配器模式 404
31.2.1 用装饰模式描述丑小鸭 404
31.2.2 用适配器模式实现丑小鸭 407
31.2.3 实践 410
第32章 行为类模式大PK 411
32.1 命令模式VS策略模式 411
32.1.1 策略模式实现压缩算法 411
32.1.2 命令模式实现压缩算法 414
32.1.3 小结 419
32.2 策略模式VS状态模式 420
32.2.1 策略模式实现人生 420
32.2.2 状态模式实现人生 423
32.2.3 小结 425
32.3 观察者模式VS责任链模式 426
32.3.1 责任链模式实现DNS解析过程 427
32.3.2 触发链模式实现DNS解析过程 432
32.3.3 小结 437
第33章 跨战区PK 438
33.1 策略模式VS桥梁模式 438
33.1.1 策略模式实现邮件发送 439
33.1.2 桥梁模式实现邮件发送 442
33.1.3 实践 445
33.2 面模式VS中介者模式 446
33.2.1 中介者模式实现工资计算 446
33.2.2 面模式实现工资计算 451
33.2.3 实践 454
33.3 包装模式K 455
33.3.1 代理模式 455
33.3.2 装饰模式 457
33.3.3 适配器模式 459
33.3.4 桥梁模式 461
33.3.5 实践 464
第四部分 完美世界—设计模式混编
第34章 命令模式+责任链模式 466
34.1 搬移UNIX的命令 466
34.2 混编小结 481
第35章 工厂方法模式+策略模式 483
35.1 迷你版的交易系统 483
35.2 混编小结 493
第36章 观察者模式+中介者模式 495
36.1 事件触发器的开发 495
36.2 混编小结 508
第五部分 扩展篇
第37章 MVC框架 510
37.1 MVC框架的实现 510
37.1.1 MVC的系统架构 512
37.1.2 模型管理器 518
37.1.3 值栈 522
37.1.4 视图管理器 522
37.1.5 工具类 526
37.2 实践 528
第38章 新模式 530
38.1 规格模式 530
38.1.1 规格模式的实现 530
38.1.2 实践 543
38.2 对象池模式 546
38.2.1 正确的池化 546
38.2.2 对象池模式的意图 547
38.2.3 实践 549
38.3 雇工模式 549
38.3.1 雇工合作 549
38.3.2 雇工模式的意图 551
38.3.3 实践 552
38.4 黑板模式 552
38.4.1 黑板模式的意图 552
38.4.2 黑板模式的实现方法 553
38.5 空对象模式 554
38.5.1 空对象模式的例子 554
38.5.2 实践 555
附录 23种设计模式彩图

---------------------------Java设计模式及实践---------------------------
精选Java实用设计模式,展示Java语言中更加智能化的编码实例
既涵盖面向对象编程、函数式编程和响应式编程模式及使用方法,又介绍从MVC架构向微服务和无服务器架构转变的发展趋势,以及Java新版本的特性及其实践
---------------------------设计模式之禅(第2版)---------------------------
同样是导演,为什么詹姆斯·卡梅隆、史蒂芬·斯皮尔伯格能够制作出令人惊心动魄的旷世巨著?同样是建筑师,为什么贝聿铭、圣地亚哥·卡拉特拉瓦能够创造出如此美丽、和谐、雄伟的建筑?同样是程序员或架构师,我们的作品又应该达到怎样的境界?诚然,技术和创造力我们都不缺,缺少的是为软件注入灵魂的方式和方法,“设计模式”正是这一系列方式和方法的集大成者。巧妙地应用设计模式可以让我们的代码更健壮、更易于理解和维护,从而显著提高系统的可靠性、稳定性、可维护性和可扩展性,这是成长为程序员和架构师的必备技能。
《设计模式之禅(第2版)》由秦小波著,“他山之石,可以攻玉”,本书以亲切、自然的风格阐述了设计模式的核心思想,潜移默化地提升我们面向对象的架构和编程能力,带我们进入“物我合一、见性成佛”的最高设计境界。

---------------------------设计模式之禅(第2版)---------------------------
大旗不挥,谁敢冲锋 —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 class to change. 这句话初中生都能看懂,不多说,但是看懂是一码事,实施就是另外一码事了。上面讲的例子很好理解,在实际项目中大家都已经这么做了,那我们再来看看下面这个例子是否好理解。电话这玩意,是现代人都离不了,电话通话的时候有4个过程发生:拨号、通话、回应、挂机,那我们写一个接口,其类图如图1-4所示。 我不是有意要冒犯IPhone的,同名纯属巧合,我们来看一个这个过程的代码,如代码清单1-2所示。 代码清单1-2 电话过程 public interface IPhone { //拨通电话 public void dial(String phoneNumber); //通话 public void chat(Object o); //通话完毕,挂电话 public void hangup(); } 实现类也比较简单,我就不再写了,大家看看这个接口有没有问题?我相信大部分的读者都会说这个没有问题呀,以前我就是这么做的呀,某某书上也是这么写的呀,还有什么什么的源码也是这么写的!是的,这个接口接近于完美,看清楚了,是“接近”!单一职责原则要求一个接口或类只有一个原因引起变化,也就是一个接口或类只有一个职责,它就负责一件事情,看看上面的接口只负责一件事情吗?是只有一个原因引起变化吗?好像不是! IPhone这个接口可不是只有一个职责,它包含了两个职责:一个是协议管理,一个是数据传送。dial()和hangup()两个方法实现的是协议管理,分别负责拨号接通和挂机;chat()实现的是数据的传送,把我们说的话转换成模拟信号或数字信号传递到对方,然后再把对方传递过来的信号还原成我们听得懂的语言。我们可以这样考虑这个问题,协议接通的变化会引起这个接口或实现类的变化吗?会的!那数据传送(想想看,电话不仅仅可以通话,还可以上网)的变化会引起这个接口或实现类的变化吗?会的!那就很简单了,这里有两个原因都引起了类的变化。这两个职责会相互影响吗?电话拨号,我只要能接通就成,甭管是电信的还是网通的协议;电话连接后还关心传递的是什么数据吗?通过这样的分析,我们发现类图上的IPhone接口包含了两个职责,而且这两个职责的变化不相互影响,那就考虑拆分成两个接口,其类图如图1-5所示。 这个类图看上去有点复杂了,完全满足了单一职责原则的要求,每个接口职责分明,结构清晰,但是我相信你在设计的时候肯定不会采用这种方式,一个手机类要把ConnectionManager和DataTransfer组合在一块才能使用。组合是一种强耦合关系,你和我都有同的生命期,这样的强耦合关系还不如使用接口实现的方式呢,而且还增加了类的复杂性,多了两个类。经过这样的思考后,我们再修改一下类图,如图1-6所示。 图1-5 职责分明的电话类图 图1-6 简洁清晰、职责分明的电话类图 这样的设计才是完美的,一个类实现了两个接口,把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化了呀,是的,但是别忘记了我们是面向接口编程,我们对外公布的是接口而不是实现类。而且,如果真要实现类的单一职责,这个就必须使用上面的组合模式了,这会引起类间耦合过重、类的数量增加等问题,人为地增加了设计的复杂性。 通过上面的例子,我们来总结一一职责原则有什么好处: q 类的复杂性降低,实现什么职责都有清晰明确的定义; q 可读性提高,复杂性降低,那当然可读性提高了; q 可维护性提高,可读性提高,那当然更容易维护了; q 变更引起的风降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。 看过电话这个例子后,是不是想反思一下了,我以前的设计是不是有点问题了?不,不是的,不要怀疑自己的技术能力,单一职责原则最难划分的就是职责。一个职责一个接口,但问题是“职责”没有一个量化的标准,一个类到底要负责那些职责?这些职责该怎么细化?细化后是否都要有一个接口或类?这些都需要从实际的项目去考虑,从功能上来说,定义一个IPhone接口也没有错,实现了电话的功能,而且设计还很简单,仅仅一个接口一个实现类,实际的项目我想大家都会这么设计。项目要考虑可变因素和不可变因素,以及相关的收益成本比率,因此设计一个IPhone接口也可能是没有错的。但是,如果纯从“学究”理论上分析就有问题了,有两个可以变化的原因放到了一个接口中,这就为以后的变化带来了风。如果以后模拟电话升级到数字电话,我们提供的接口IPhone是不是要修改了?接口修改对其他的Invoker类是不是有很大影响? 注意 单一职责原则提出了一个编写程序的标准,用“职责”或“变化原因”来衡量接口或类设计得是否优良,但是“职责”和“变化原因”都是不可度量的,因项目而异,因环境而异。 1.3 我单纯,所以我快乐 对于接口,我们在设计的时候一定要做到单一,但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增,给维护带来非常多的麻烦,而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类,然后再使用聚合或组合的方式耦合在一起,人为制造了系统的复杂性。所以原则是死的,人是活的,这句话很有道理。 单一职责原则很难在项目中得到体现,非常难,为什么?在国内,技术人员的地位和话语权都比较低,因此在项目中需要考虑环境,考虑工作量,考虑人员的技术水平,考虑硬件的资源情况,等等,最终妥协的结果是经常违背单一职责原则。而且,我们中华文明就有很多属于混合型的产物,比如筷子,我们可以把筷子当做刀来使用,分割食物;还可以当叉使用,把食物从盘子中移动到口中。而在西方的文化中,刀就是刀,叉就是叉,你去吃西餐的时候这两样肯定都是有的,刀就是切割食物,叉就是固定食物或者移动食物,分工很明晰。这种文化的差异很难一步改造过来,但是我相信随着技术的深入,单一职责原则必然会深入到项目的设计中,而且这个原则是那么的简单,简单得不需要我们更加深入地思考,单从字面上大家都应该知道是什么意思,单一职责嘛! 单一职责适用于接口、类,同时也适用于方法,什么意思呢?一个方法尽可能做一件事情,比如一个方法修改用户密码,不要把这个方法放到“修改用户信息”方法中,这个方法的颗粒度很粗,比如图1-7中所示的方法。 图1-7 一个方法承担多个职责 在IUserManager中定义了一个方法changeUser,根据传递的类型不同,把可变长度参数changeOptions修改到userBO这个对象上,并调用持久层的方法保存到数据库中。在我的项目组中,如果有人写了这样一个方法,我不管他写了多少程序,花了多少工夫,一律重写!原因很简单:方法职责不清晰,不单一,不要让别人猜测这个方法可能是用来处理什么逻辑的。 比较好的设计如图1-8所示。 通过类图可知,如果要修改用户名称,就调用changeUserName方法;要修改家庭地址,就调用changeHomeAddress方法;要修改单位电话,就调用changeOfficeTel方法。每个方法的职责非常清晰明确,不仅开发简单,而且日后的维护也非常容易,大家可以逐渐养成这样的习惯。 图1-8 一个方法承担一个职责 所以,如果对接口、类、方法使用了单一职责原则,那么快乐的就不仅仅是你了,还有你的项目组成员,大家可以轻松而又愉快地进行开发;还有你的老板,减少了因为变更引起的工作量,减少了无谓的人员和资金消耗。当然,最快乐的也许就是你了,因为加官晋爵可能等着你哟! 1.4 实践 阅读到这里,可能有人会问我,你写的是类的设计原则吗?你通篇都在说接口的单一职责,类的单一职责你都违背了呀!呵呵,这个还真是的,我的本意是想把这个原则讲清楚,类的单一职责嘛,这个很简单,但当我回头写的时候,发觉并不是这么回事,翻看了以前的一些设计和代码,基本上拿得出手的类设计都是与单一职责相违背的。静下心来回忆,发觉每一个类这样设计都是有原因的。我查阅了Wikipedia、OODesign等几个网站,专家和我也有类似的经验,基本上类的单一职责都用了类似的一句话来说“This is sometimes hard to see”,这句话翻译过来就是“这个有时候很难说”。是的,类的单一职责确实受非常多因素的制约,纯理论地来讲,这个原则是非常的,但是现实有现实的难处,你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政策、垄断协议等因素。比如,2004年我就做过一个项目,做加密处理的,甲方就甩过来一句话,你什么都不用管,调用这个API就可以了,不用考虑什么传输协议、异常处理、安全连接等。所以,我们就直接使用了JNI与加密厂商提供的API通信,什么单一职责原则,根本就不用考虑,因为对方不公布通信接口和异常判断。 对于单一职责原则,我的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。

---------------------------Java设计模式及实践---------------------------
借助设计模式,开发者可以改进代码库,提高代码可重用性,并使技术架构更加健壮。随着编程语言的不断发展,新的语言特性在得到广泛应用之前往往需要大量时间去理解。本书旨在降低接受最新趋势的难度,为开发人员提供良好的实例。
本书的目标读者
本书适用于每一位有意愿编写高质量代码的Java开发人员。本书讲述了很多开发者在编码时经常疏忽的实践。书中涵盖了许多设计模式,这些设计模式经开发团队实践和测试过,是用来解决特定问题的方案。
本书内容
第1章介绍了Java语言不同的编程范式。
第2章介绍了多种设计模式中的创建型模式,讲述了多种类型的创建型设计模式。
第3章介绍了行为型设计模式,主要解析了多种用来管理代码和对象行为的设计模式。
第4章介绍了结构型设计模式,详细解析了用于管理对象结构的设计模式。
第5章向读者介绍了函数式编程及与之相关的设计模式。
第6章通过实例介绍了响应式编程及其Java实现。
第7章进一步探索了响应式编程的核心内容及与之相关的设计模式。
第8章从MVC架构到微服务和无服务器应用,探索了近年来开发者尝试和测试过的多种架构模式。
第9章介绍了Java的历史、实践和最新版Java中的更新,并在最后表达了作者对Java未来的期待。
如何充分利用本书
拥有Java开发经验者将能从本书中获益良多,推荐读者在阅读过程中探索并充分实践各章中提供的示例代码。
下载示例代码及彩色图像
本书的示例代码及所有截图和图表,可以从http://www.packtpub.com通过个人账号下载,也可以访问华章图书官网http://www.hzbook.com,通过注册并登录个人账号下载。
---------------------------设计模式之禅(第2版)---------------------------
为什么写这本书 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和混编设计模式两部分内容教你如何自如地去运用这些设计模式,这是当前所有设计模式类的图书都不具备的,连最权威的那本书也不例外。 我很讨厌技术文章中夹杂着的那些晦涩难懂的文字,特别是一堆又一堆的名词堆砌,让人看着就反胃。但是为了学习技术,为了生存,还是必须看下去。国内的技术文档,基本上都是板着一副冷面孔讲技术,为什么要把技术弄得这么生硬呢?技术也有它幽默、柔情的一面,只是被我们的“孔夫子们”掩盖了,能用萝卜、白菜这种寻常人都熟悉的知识来讲解原子弹理论的人,那是牛人,我佩服这样的人。记住,用一堆名词把你晕的人很可能什么都不懂! 本书想告诉你的是,技术也可以很有乐趣,也可以让你不用皱着眉头思考,等待你的只是静静地看,慢慢地思考,本书的内容会润物细无声地融入你的思维中。 本书面向的读者 热爱技术并且讨厌枯燥乏味技术文章的读者都可以看本书; 你是程序员,没问题,本书能够让你写出更加高效、优雅的代码; 你是架构师,那更好,设计模式可让你设计出健壮、稳定、高效的系统,并且自动地预防未来业务变化可能对系统带来的影响; 你是项目经理,也OK,设计模式可以让你的工期大大缩短,让你的项目团队成员快速地理解你的意图,最终的成果就是优质的项目:高可靠性、高稳定性、高效率和低维护成本。 如何阅读本书 首先声明,本书中所有的例子都是用Java语言来实现的,但是你可以随手翻翻看,基本上能保证每三条语句一个注释,可以说是在用咱们的母语讲解设计模式。即使你不懂Java语言,也没有关系,只要知道在Java中双斜杠(//)代表注释就足够了,况且Java如此强大和盛行,多了解一点没有坏处。类图看不懂?没关系,不影响你理解设计模式,多看看就懂了! 如果你还没有编程经验,我建议你把它当做小说来看,懂行的看道,不懂行的看热闹,这里的热闹足够多,够你看一壶的了。你现在能看懂多少是多少,不懂没有关系,你要知道,经验不是像长青春痘一样,说长就长出来了,它是需要时间积累的,需要你用心去感受,然后才能明白为什么要如此设计。 如果你已经对编程有感觉了(至少两年开发经验),我相信你都能看懂,但能“懂”到什么程度,就很难说了,看你的水平了。但是,我可以保证,这里的设计模式都是你能看懂的,没有你看不懂的!我建议你通读这本书,然后挑你最得意的编程语言,动手写吧!给自己制定一个计划,每天编写一段代码,不需要太多,200行足够,时不时地把设计模式融入你的代码中。甭管是什么代码,比如你想编写一个识别美女图片的程序,好呀,抓紧时间去写吧,写好了就不用到处看美女了,程序一跑就把网上的美女图片都抓过来了,牛呀(记住,程序写好了要分享给我)。看吧,坚持下去,一年以后你再跟你的同侪比较一下,那差距肯定不是一般的大。 如果你是工程师、架构师、技术顾问等高等级的技术人员,那我告诉你,你找对这本书了。系统架构没有思路?没有问题,看看扩展部分,它会开阔你的思路。系统的维护成本居高不下?看看本书,设计模式也许能帮你省点银子。开发资源无法保证?设计模式能让你用有限的资源(软硬件资源和人力资源)设计出一个的系统。项目质量参差不齐,缺陷一大堆?多用设计模式,它会给你意想不到的效果。给人讲课没有素材?没问题,本书中的素材足以让你赢得阵阵掌声! 编程是一艺术活,我有一个同事,能把类图画成一个小乌龟的形状,天才呀!作为一位技术人员,最基本的品质就是诚实,“知之为知之,不知为不知,是知也”,自己不懂没有关系,去学,学无止境,但是千万不要贪多,这抓一点,那挖一点,好像什么都懂,其实什么都不懂。中国一直推崇复合型人才,我不是很赞成,因为这对年轻人来说是一个误导。先精一项技术,然后再发散学习,先点后面才是正道。 记得《武林外传》中有这样一段对话: 刑捕头:手中无刀,心中有刀。 老白:错了,最高境界是手中无刀,心中也无刀。 体验一下吧,我们的设计模式就是一把刀,的境界就是心中无设计模式,代码亦无设计模式—设计模式随处可见,俯拾皆是,已经融入软件设计的灵魂中,这才是高手中的高手,简称高高手。 哦,最最重要的忘记说了,请把附录中的“23种设计模式附图”撕下来,贴在你的办公桌前,时不时地看看,也让老板看看,咱是多么地用心! 关于书名 乍一看,书名和内容貌似不相符呀,其实不然! 在我们的常规思维中,“禅”应该是很高深的东西,只可意会,不可言传。没错,禅宗也是如此说。禅是得道者的“悟”,是不能用言语来表达的,但是得道者为了能让更多的人“悟”,就必须用最容易让人理解的文字把自己的体会表达出来。本书的“禅”是作者对设计模式的“悟”,本书的“形”就是你现在看到的这些极其简单、通俗、易懂的文字。 至此,大家应该不会再对书名有疑虑了吧,嘿嘿。 致谢 本书第1版的写作耗时7个月,第2版的更新又花了4个月,可以说是榨干了海绵里所有的水—基本上能用的时间都用上了。在公交车上打腹稿,干过!在马桶上查资料,干过!在睡梦中思考案例,也有过!就差没有走火入魔了! 首先,感谢杨福川编辑,没有他的慧眼,这本书不可能出版。其次,感谢妻子和儿子,每天下班回到家,一按铃,儿子就在里面叫:“我来开,我来开。”儿子三岁,太调皮了,他不睡觉我基本上是不能开写的,我一旦开始写东西,他就跑过来问:“爸爸,你在干什么呀”,紧接着下一句就是“爸爸,你陪我玩”,基本都是拿我当玩具,别的小朋友都是把父亲当马骑,他却不,他把我当摩托车骑,还要加油,发动……小家伙脚太重了,再骑摩托,非被他踩死不可! 还要感谢我的朋友王骢,周末只要小家伙在家,我只有找地方写书的份儿,王骢非常爽快地把钥匙给我,让我有一个安静的地方写书。一个人沉浸在自己喜欢的世界里也是一件非常幸福的事。 当然,还要感谢JavaEye上所有顶帖的网友,没有你们的支持我就没有写作的动力,就像希腊神话中的巨人安泰失去了大地的力量一样,是你们的回帖让我觉得不孤单,让我知道我不是一个人在战斗! 最后,再次对本书中可能出现的错误表示歉意,真诚地接受大家轰炸!如果你在阅读本书时发现错误或有问题想讨论,请发邮件给我。
 

售后保障

最近浏览

猜你喜欢

该商品在当前城市正在进行 促销

注:参加抢购将不再享受其他优惠活动

x
您已成功将商品加入收藏夹

查看我的收藏夹

确定

非常抱歉,您前期未参加预订活动,
无法支付尾款哦!

关闭

抱歉,您暂无任性付资格

此时为正式期SUPER会员专享抢购期,普通会员暂不可抢购