软件框架设计的艺术

 

评论：

　　十年难得一遇的佳作，通过阅读本书， Java程序员必将取得长足的进步。
                                                                        ——亚马逊读者评论
　　这绝对是一本不容错过的好书，据我所知，市场上还不曾有哪本书在框架设计领域有如此深刻的阐述。                                                               　　　　　　　　　　　　　　　　　　　　——亚马逊读者评论

　　这本书是作者对自己十多年NetBeans开发的一个总结。他将自己的心路历程如实记下，见证了NetBeans从IDE走向平台、从混乱的代码走向清晰的 模块化架构这一不平凡的历程。……本书与其他设计书籍的迥异之处：它告诉读者的是一种大道，而非小技。                            　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ——本书译者
内容简介：
　　敏捷API设计的时代才刚刚开始，这本书堪称是API设计的一部开风气之先的著作。

　　与枯燥乏味的理论性图书不同，本书从理论、实战及日常应用三个方面详细讲解了软件开发和框架设计的艺术，着眼于保证软件设计能够应对时刻变化的需求和技术。书中将理论与实践有机地结合在一起，对框架设计领域进行了深层次的阐释。

　　作为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 文本信息也是API        30
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 满城尽是Lookup        121
7.6 Lookup的滥用        126
第8章 设计API时要区分其目标用户群        129
8.1 C和Java语言中如何定义API和SPI        129
8.2 API演进不同于SPI演进        131
8.3 java.io.Writer这个类从JDK 1.4到JDK 5的演进        131
8.4 合理分解API        143
第9章 牢记可测试性        147
9.1 API设计和测试        148
9.2 规范的光环正在褪去        151
9.3 好工具让API设计更简单        153
9.4 兼容性测试套件        155
第10章 与其他API协作        158
10.1 谨慎使用第三方API        158
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 不要害怕发布一个稳定的API        252
14.4 降低维护费用        255
第15章 改进API        258
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 分解庞大的API        352
第20章 未来        356
20.1 原则性内容        357
20.2 无绪长存        358
20.3 API设计方法论        360
20.4 编程语言的演变        361
20.5 教育的作用        363
20.6 共享        365
参考书目        366