作者：[捷]JaroslavTulach 日期：2017-02-20 21:19:05
本书帮助你解决API 设计方面的问题，共分3 个部分，分别指出学习API 设计是需要进行科学的训练的、Java 语言在设计方面的理论及设计和维护API 时的常见情况，并提供了各种技巧来解决相应的问题。
本书作者是NetBeans 的创始人，也是NetBeans 项目最初的架构师。相信在API 设计中遇到问题时，本书将不可或缺。
本书适用于软件设计人员阅读。
作者简介
Jaroslav Tulach NetBeans的创始人，也是NetBeans项目最初的架构师。有着丰富的项目开发经验，一直致力于如何提高开发人员的设计技巧，从而保证了NetBeans项目的成功。
目录：
第一部分 理论与理由
第1章 软件开发的艺术4
1.1 理性主义，经验主义以及无绪4
1.2 软件的演变过程6
1.3 大型软件8
1.4 漂亮，真理和优雅9
1.5 更好的无绪12
第2章 设计API的动力之源14
2.1 分布式开发14
2.2 模块化应用程序16
2.3 交流互通才是一切20
2.4 经验主义编程方式22
2.5 开发第一个版本通常比较容易24
第3章 评价API好坏的标准26
3.1 方法和字段签名26
3.2 文件及其内容27
3.3 环境变量和命令行选项29
3.4 文本信息也是API30
3.5 协议32
3.6 行为35
3.7 国际化支持和信息国际化35
3.8 API的广泛定义37
3.9 如何检查API的质量37
3.9.1 可理解性37
3.9.2 一致性38
3.9.3 可见性39
3.9.4 简单的任务应该有简单的方案40
3.9.5 保护投资40
第4章 不断变化的目标42
4.1 第一个版本远非完美42
4.2 向后兼容43
4.2.1 源代码兼容43
4.2.2 二进制兼容44
4.2.3 功能兼容——阿米巴变形虫效应50
4.3 面向用例的重要性52
4.4 API设计评审55
4.5 一个API的生命周期56
4.6 逐步改善60
第二部分 设计实战
第5章 只公开你要公开的内容67
5.1 方法优于字段68
5.2 工厂方法优于构造函数70
5.3 让所有内容都不可更改71
5.4 避免滥用setter方法72
5.5 尽可能通过友元的方式来公开功能73
5.6 赋予对象创建者更多权利77
5.7 避免暴露深层次继承82
第6章 面向接口而非实现进行编程85
6.1 移除方法或者字段87
6.2 移除或者添加一个类或者接口88
6.3 向现有的继承体系中添加一个接口或者类88
6.4 添加方法或者字段88
6.5 Java中接口和类的区别90
6.6 弱点背后的优点91
6.7 添加方法的另一种方案92
6.8 抽象类有没有用呢94
6.9 要为增加参数做好准备95
6.10 接口VS.类97
第7章 模块化架构98
7.1 模块化设计的类型100
7.2 组件定位和交互103
7.3 编写扩展点116
7.4 循环依赖的必要性117
7.5 满城尽是Lookup121
7.6 Lookup的滥用126
第8章 设计API时要区分其目标用户群129
8.1 C和Java语言中如何定义API和SPI129
8.2 API演进不同于SPI演进131
8.3java.io.Writer这个类从JDK 1.4到JDK 5的演进131
8.4 合理分解API143
第9章 牢记可测试性147
9.1 API设计和测试148
9.2 规范的光环正在褪去151
9.3 好工具让API设计更简单153
9.4 兼容性测试套件155
第10章 与其他API协作158
10.1 谨慎使用第三方API158
10.2 只暴露抽象内容162
10.3 强化API的一致性164
10.4 代理和组合168
10.5 避免API的误用176
10.6 不要滥用JavaBeans那种监听器机制180
第11章 API具体运行时的一些内容184
11.1 不要冒险186
11.2 可靠性与无绪189
11.3 同步和死锁191
11.3.1 描述线程模型192
11.3.2 Java Monitors中的陷阱193
11.3.3 触发死锁的条件196
11.3.4 测试死锁201
11.3.5 对条件竞争进行测试204
11.3.6 分析随机故障206
11.3.7 日志的高级用途208
11.3.8 使用日志记录程序控制流程210
11.4 循环调用的问题215
11.5 内存管理218
第12章 声明式编程223
12.1 让对象不可变225
12.2 不可变的行为229
12.3 文档兼容性230
第三部分 日常生活
第13章 极端的意见有害无益236
13.1 API必须是漂亮的237
13.2 API必须是正确的237
13.3 API应该尽量简单240
13.4 API必须是高性能的242
13.5 API必须绝对兼容242
13.6 API必须是对称的245
第14章 API设计中的矛盾之处247
14.1 API设计中的自相矛盾248
14.2 背后隐藏的工作251
14.3 不要害怕发布一个稳定的API252
14.4 降低维护费用255
第15章 改进API258
15.1 让有问题的类库重新焕发活力259
15.2 自觉地升级与无意识地被迫升级265
15.3 可选的行为268
15.4 相似API的桥接和共存274
第16章 团队协作286
16.1 在提交代码时进行代码评审286
16.2 说服开发人员为他们的API提供文档290
16.3 尽职尽责的监控者292
16.4 接受API的补丁297
第17章 利用竞赛游戏来提升API设计技巧300
17.1 概述300
17.2 第一天301
17.2.1 非public类带来的问题304
17.2.2 不可变性带来的问题304
17.2.3 遗漏实现的问题308
17.2.4 返回结果可能不正确的问题309
17.2.5 第一天的解决方案310
17.3 第二天313
17.3.1 我想修正犯下的错误316
17.3.2 第二天的解决方案317
17.4 第三天：评判日320
17.5 也来玩下这个游戏吧327
第18章 可扩展Visitor模式的案例328
18.1 抽象类331
18.2 为改进做好准备333
18.3 默认的遍历334
18.4 清楚地定义每个版本337
18.5 单向改进339
18.6 使用接口时的数据结构340
18.7 针对用户和开发商的Visitor模式341
18.8 三重调度343
18.9 Visitor模式的圆满结局345
18.10 语法小技巧346
第19章 消亡的过程348
19.1 明确版本的重要性349
19.2 模块依赖的重要性349
19.3 被移除的部分需要永久保留吗352
19.4 分解庞大的API352
第20章 未来356
20.1 原则性内容357
20.2 无绪长存358
20.3 API设计方法论360
20.4 编程语言的演变361
20.5 教育的作用363
20.6 共享365
参考书目366