软件框架设计的艺术
当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 软件框架设计的艺术
出版社:人民邮电出版社
出版日期:2011-3
ISBN:9787115248497
作者:[捷] Jaroslav Tulach
页数:388页
前言
对于《软件框架设计的艺术》，我有一种相见恨晚的感觉，相信很多读者在读后也会有同感。 多年的软件开发经验让我体会到了各种酸甜苦辣的滋味，很多开发人员对此都应感同身受。除了这些滋味，最常出现的却是迷茫：碰到问题，却无法解决；解决问题，却无法避免同样的错误一犯再犯。这一次次的迷茫，对每一位软件开发人员都会带来沉重的打击。幸好，这个世界上总不乏先行者为我们点亮一盏盏明灯，也总有大师级人物为我们指点迷津。阅读他们的著述，便有一种醍醐灌顶的顿悟，如Gamma等人的《设计模式》、Bloch的Effective Java，这些书常令我掩卷而叹：原来如此！而此刻你手中拿到的也正是这样的一本书。 提到这本书，就不能不提到作者Jaroslav Tulach。作为NetBeans的创始人，十多年来，他一直致力于NetBeans产品的开发，并赢得了开源社区的尊重和美誉。这本书是他对自己十多年NetBeans开发的一个总结。他将自己的心路历程如实记下，见证了NetBeans从IDE走向平台、从混乱的代码走向清晰的模块化架构这一不平凡的历程。这一路走来并不平坦，但他终在每一次迷茫和困惑中找到了完善的解决方案。在本书中，从API的设计思想、兼容性解决方案到编码的技术要点，他都娓娓道来，与我们一同分享。 读者也许会问：此书与市场上同类的设计书籍相比有何突出之处呢？我们不妨想想，近十年蓬勃发展的开源运动，引无数英雄竞折腰。而为什么有些开源框架或者系统能够快速地拥有大量用户并维持下去，但自己开发的类库、软件却无法取得类似的成功呢？我想告诉读者，答案尽在此书中。这就是本书与其他设计书籍的迥异之处：它告诉读者的是一种大道，而非小技。 坦诚地说，本书不是写给初学者的，即使是有经验的开发人员，深读此书也并非易事。但我仍然确信，不论是一位富有经验的架构师还是一位堪堪入门的初学者，只要他细心研读，就能从本书中有所收获。本书不应读过后就束之高阁，而应常备于手边。当遇到难思难解之事时，翻翻此书，必有意想不到之收获。还可以将此书放于案头，闲暇之时读上几页，必有所得。 翻译本书决非一件轻松的工作，但于我，无论多苦多累，都是值得，应该说翻译本书带给我更多的是收获。我也希望这本书可以为读者带来同样的收获。人民邮电出版社图灵公司给了我足够的时间和自由度来翻译本书，对此致以我最真诚的谢意。受限于自身的水平，书中若有翻译不到位或不妥之处，责任尽归于本人，烦请各位读者谅解一二。 王磊 2011年早春
媒体关注与评论
这绝对是一本不容错过的好书，据我所知，市场上还不曾有哪本书在框架设计领域有如此深刻的阐述。——亚马逊读者评论 这本书是作者对自己十多年NetBeans开发的一个总结。他将自己的心路历程如实记下，见证了NetBeans从IDE走向平台、从混乱的代码走向清晰的模块化架构这一不平凡的历程。……本书与其他设计书籍的迥异之处：它告诉读者的是一种大道，而非小技。——本书译者
内容概要
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
作者简介
本书帮助你解决API 设计方面的问题，共分3 个部分，分别指出学习API 设计是需要进行科学的训练的、Java 语言在设计方面的理论及设计和维护API 时的常见情况，并提供了各种技巧来解决相应的问题。
本书作者是NetBeans 的创始人，也是NetBeans 项目最初的架构师。相信在API 设计中遇到问题时，本书将不可或缺。
本书适用于软件设计人员阅读。
图书封面
发布书评
精彩书评 (总计11条)
-
正如本书作者在序言中问到“仅仅是又多了一本设计书吗？”作者相信本书的存在“自有其必要性”，原因在于本书探讨的设计领域是如此的卓尔不群，却又是Java程序员在开发中必须要面对的问题，那就是框架的设计，API的设计。 我自认为对面向对象设计的掌握已经深入骨髓，对设计模式也算得上了然于胸，可在阅读本书时，我才发现自己所知不过是米粒之珠，对象设计原来还有更加广阔的世界。API设计的不同，已经超出了通常的面向对象设计讨论的范围。API的演化需要考虑的因素，比起一般的接口与类的设计，要更加地复杂与困难。面向对象设计有一个非常重要的原则是“开放-封闭原则（OCP），利用抽象以应对扩展，利用封装以隐藏实现，从而避免修改。这是我们在设计中需要遵循的一条重要法则。但我始终认为，要达成真正的开放与封闭，实则是一种遥不可及的理想，在现实的开发过程中，能做到修改尽量少，扩展尽量容易，就已经不错了。然而，对于一个已经拥有大量用户群体的框架与API而言，则必须追求OCP至极致，否则就会因为实现的不稳定性与版本的不兼容性，而被原有客户抱怨，甚至被抛弃。这正是框架设计与通常的企业应用系统设计最大的不同。托尔斯泰说过：“幸福的家庭总是相似的，而不幸的家庭则各有各的不幸。”设计亦然。好的设计原则可以放之四海而皆准，而设计的缺陷却各有各的表现特征。本书的最大特点是围绕着NetBeans的开发来说事儿，诉说其渊源、演化与设计的过失。这是真实的实践，不是拿着可笑的玩具项目阐释设计原则的方式所能比拟的。也许它失之于晦涩艰深，但只要你愿意仔细研磨，收获定能远超阅读的付出。不过，如果你是一位Java初学者，那就奉劝你远离此书，它会比“云计算”还要让你云里雾里。或许，你的职业发展目标，应以读懂本书为一个重要的里程碑。当你明白本书讲解的知识时，也许你已经可以驾驭面向对象设计与API设计了。阅读本书最好能结合NetBeans的源代码一起分析，如此方能领会设计之妙。其实在我看来，这是本书的硬伤。因为作者在讲解设计问题时，实在太罗嗦了。所谓“一图胜千言”，而对于我们这些代码狂热者而言，代码的清晰度远甚于冗长的描述。书中列出的UML图与代码实在太少了，通篇的文字描述让我们在阅读时感觉有些乏味。以我小人之心，会认为本书作者包藏“祸心”，因为本书可以大肆地推广NetBeans，他好像在说“读不懂吗？不明白吗？那快去下载NetBeans啊！”可惜我们必须接受这样的诱惑，因为读懂这本书的内容绝对能够让你的设计能力登上一个大大的台阶。Rod Johnson的名著Expert One-to-One J2EE Development without EJB，在书名中并未提到Spring，但书中对Spring设计的阐释，也许比任何一本Spring著作都要通透与权威，因为Rod Johnson正是Spring之父。本书的英文名Practical API Design同样没有提到NetBeans，但若要论NetBeans中的设计原则，本书作者Jaroslav Tulach自然是最佳选择，因为他正是NetBeans之父。在JavaLobby对他的采访（人民邮电出版社编辑李松峰在其博客上翻译了这篇采访）中，Jaroslav Tulach提到了写作本书的心路历程：“写这本书的素材我已经收集了10年之久了，因此我知道这本书绝不可能在短时间内写完。自从去年夏天，我表弟促使我下定决心之后，写这本书大概花了整整一年时间，包括整理笔记和修改润色。”可以说，本书事实上是伴随着NetBeans的成长而孕育成熟直至诞生。本书为我们描绘了API设计的壮丽画卷，这里的景色美不胜收，又仿佛如蒙娜丽莎的微笑那般神秘。在设计的旅途中，我们充满敬畏，却又应保持足够的怀疑，这是我一直以来的阅读态度。本书我已经阅读到了第15章。书中提到的许多设计技巧与原则，让我欣喜不已；然而也有许多讲解让我疑惑。当我发现，为了保证API的向后兼容，不得不牺牲设计上的优雅与美时，这让我有些不快，却又必须无奈地接受现实。还有5章的内容，我就要结束本书的阅读了。然而，这仅仅是开始，因为我对书中许多内容依旧抱有困惑，甚至没能明白个中含义。我还需要阅读第二遍，第三遍……经典的书籍就应该这样阅读。摘自：http://www.infoq.com/cn/news/2011/06/practical-api-design -
以扯淡为主，轻松好看，不要指望是一本很有含量的书，就象闲侃，你不要要求那么多，牛B的人跟你闲侃，不要想从中得到诸多专业的知识字数不够，好吧，总结下：这本书是闲谈某个软件开发的架构的一些问题，相当于论坛帖子集合 够了吗？ -
大部分的篇幅在扯淡，感觉整个书的主题是如何设计前后兼容的API。大部分在讲一些设计API的小技巧，基本没有涉及到如何设计完整的软件框架。没看过的没必要花时间看了，还不如看看这个：Java API Design Checklist，http://dongxi.net/b14gn。
精彩短评 (总计47条)
-
可能更适合 Java... -
这本书读起来稍微有点晦涩，主要因为它的背景以GUI和netbean作为主要平台，和现在主流技术有些差别，另外对于普通的设计（非API级别且不大考虑兼容）而言又相去甚远，而且有部分章节显得啰嗦和累赘，但无论如何无绪的思想以及非常精彩的API与SPI分离，以及模块化架构的阐述值得大赞 -
看了之后就忍不住去下了netbeans开发java，作者将API以艺术的形式写出来，本书不仅在内容上易懂，而且文笔卓绝忍不住看了又看。 -
从序言看就知道是一本好书 -
我极不赞成该书中“阅读指南”中有关“败笔”的观点。软件API化，能使你的软件工程钢架化——稳固、结构清晰、复用性强。团队中的成员不可能每一位都是绝顶高手，API化可以促使每一位团队成员强化思考，思考“自留地”的独立性与外部空间信息交换的简洁性。该书最值得称道的是书名没有生硬地译为“API设计”而是“框架设计”，译者完全理解了该书的精髓——API化的软件需要软件工程框架化的哲学作支撑。因此，该书的第一部分不要跳过去，如果你想成为架构师而不是编码员的话。 -
关于API设计的好书，可惜没空看。 -
有闪光点，也有不靠谱的长篇累牍。不少示例代码过于随意。 -
不好看 -
不管是作者还是翻译者都很有负责感, 内容很有思想性, 看完后思想境界提升了不少 -
印刷质量也可以，就是觉得翻译的太学院派了，能不能不正这么多玄乎的词，正在研读 -
新书到了，质量不错，纸箱包装，赞一个，开始好好学习，天天向上 -
#等我写java了一定再回来看这本书=.=# -
本书原著带有Java社区偏见、内容冗长，翻译还很晦涩。但对于初学编程关心API设计，有志于成为架构师的人，本书有用。
对于其他人嘛——本书治疗失眠效果好，建议睡前看。
我看这书能把我大脑从亢奋状态迅速变成想睡状态，合上书就睡着了。第二天早起精神好，吃嘛嘛香。
-
经验类的书籍，内容怎么都不嫌多。初略翻了一遍，是本好书。 -
太跟NetBeans相关了，很多地方没太读懂。 -
不太适合初学者阅读 -
总的来说框架可以这样看,一来是为了规范团队开发的,相同的命名规范,相同的接口,相同的实现方式,二来是为了分离部分底层逻辑的,直接使用更加抽象的思维进行开发,忽略底层的io,数据库,类库加载之类的操作,基本上可以说是为了实现敏捷开发,三来么可以说是留人之策,把你培训成代码工人,你想走也无处可去,毕竟依靠框架做项目的开发人员待遇都不会很高的,除非你转去做架构之类的,但是这些东西你在使用框架的时候是根本接触不到的,做久了员工也就不怎么想跳了,留住50%的老员工绝对没有什么问题,四来就是新人上手快,即使这娃再怎么笨,框架良好的封装,最小化的用户接口也能让他基本上不怎么犯错,即便不了解深层的原理也可以实现很多功能,这样一来降低了成本(人力资源成本),毕竟新人的薪水都不怎么高的说,除非是天才型的 -
还是老外的书看着比较好 -
纸张非常极其差，都没心情看下去了，什么玩意儿。 -
本书主线是软件版本兼容。明显能感受到作者在这方面确实经验丰富，通读下来能领会到不少其他书籍较少涉及的知识。未给满分是因为其中一些介绍的技巧过于繁复，而其目的主要是解决兼容问题。这一点在Java的模块化和接口默认方法实现的趋势下显得不甚必要。另外翻译者过多无足轻重的页脚注释有画蛇添足之嫌。 -
随便浏览了一遍,有空有用时再细读 -
更正下...翻译很水... -
作者懂不少物理学知识啊，写的不错，翻译也挺用心 -
C/C 程序员也该读 -
这其实是一本教你如何在开发中与人保持原则和平衡的书，它描述了代码作为服务提供者的原则和策略。
由于内容绝大部分都来自开发一线，因此推荐大家在读本书之前扎实一下JDK相关的基础和核心特性。
结构上，一些来自特别语境的细节对主体框架带来了干扰，需要读者在上下文中保持更多的前提，在一定程度上降低了本书的易读性 -
其实是API设计的艺术。作者是NetBeans的创始人。本书是他多年经验的分享，非常精彩。在声明式编程里，作者也表示了对函数式语言的推崇，比如函数式语言可以通过不可变的数据结构来避免死锁。让我对函数式语言的好奇心又增加了，有机会要看看。 -
书写的不好，不建议买，里面的内容感觉只到了草稿的水平，不像书。 -
看起来我买错书了 -
明明是API设计艺术。翻译的不好。 -
只暴露必要的。
分离api与spi。
维护和改进接口必须考虑用户的投资。
系统内部要模块化，模块间访问也只通过接口进行交流。
-
写得有点乱，不够深入浅出，不是很易懂。条理也有些不清。或许是自己功力还不够吧 -
以『无绪』作为API的终极目标。 -
借阅，无笔记 -
7号定的,转天上午就到了,够快,书都包着塑料膜,赞一个.书更适合做长期项目的,对后期的维护和扩展都有所帮助,可以感觉出当时NetBeans的开发所遇到的困难. -
果断推荐啊。 -
更加偏向于API的设计 -
看了几章，觉得很不错 -
到底是原文，还是翻译的问题，部分章节真啰嗦。 -
当成字典来看，关键时候查一查 -
2012年买的，今年6月才开始看。今天艰难的看到35页，感觉作者是在不断的唠叨，象祥林嫂一样，可是祥林嫂说清了故事，作者却拖拉着靠字数骗稿费。翻译人员没有问题，是个有技术功底翻译者。近400页的内容，我觉得可以砍掉一半。也许作者是学哲学的，我们这些开发人员看得太辛苦了。书托太多了....(2013/09/07)艰难地看到了第10章，不知道看了什么。丢之浪费，看之烦人，保持上面的评论。 -
xxx艺术这译名。。内容是真不错，实践经验分享和总结。好书。 -
很不错的东西，下次继续购买。 -
需要再读一遍，便于潜移默化的在实践中运用。 -
书中很多准则，已经不知不觉应用于工作中，所以很多章节就浏览了一遍，不过有很多细节还是很有意思的，对一API工作者来说，是一本必读的书，就是一般开发人员通读此书，也有助于将自己的代码变优雅，书中有很多观点和是相互印证的。 -
这本书很多地方还是有些超出我的知识范围。希望以后能重新读一遍。这本书真的很好，而且我也花了太多的时间去读。平均下来估计一个小时不到30页。 -
是本好书，值得慢慢看，但我只花一天看完，眼睛又涨又难受，shit -
这书不错