出版社: 人民邮电出版社
出品方: 图灵教育
原作名: Practical API Design: Confessions of a Java Framework Architect
译者: 王磊 / 朱兴
出版年: 2011-3
页数: 388
定价: 75.00元
装帧: 平装
丛书: 图灵程序设计丛书·程序员修炼系列
ISBN: 9787115248497
内容简介 · · · · · ·
本书帮助你解决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章 软件开发的艺术 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
· · · · · · (收起)
"软件框架设计的艺术"试读 · · · · · ·
对于本书,我有一种相见恨晚的感觉,相信很多读者在读后也会有同感。 多年的软件开发经验让我体会到了各种酸甜苦辣的滋味,很多开发人员对此都应感同身受。除了这些滋味,最常出现的却是迷茫:碰到问题,却无法解决;解决问题,却无法避免同样的错误一犯再犯。这一次次的迷茫,对每一位软件开发人员都会带来沉重的打击。幸好,这个世界上总不乏先行者为我们点亮一盏盏明灯,也总有大师级...
原文摘录 · · · · · ·
-
it isn’t useful to listen to people just because they are older or just because they have more experience.If their advice is genuinely useful,there should be evidence to support their assertions. (查看原文) —— 引自第269页 -
if everything works as it should, then nothing happens, and it’s difficult to present “nothing” as a big success. (查看原文) —— 引自第283页
丛书信息
喜欢读"软件框架设计的艺术"的人也喜欢的电子书 · · · · · ·
喜欢读"软件框架设计的艺术"的人也喜欢 · · · · · ·
软件框架设计的艺术的话题 · · · · · · ( 全部 条 )



软件框架设计的艺术的书评 · · · · · · ( 全部 12 条 )

又一本扯淡的书,还可以

思想未必是最新、最独特的,但一定是有用的

经典的书籍应该这样读
> 更多书评 12篇
-
模块化 是随着复杂度提高的一种必须,从更高层次解决混乱,提高内聚,更容易维护。 想来spring3之后分成那么多的模块是很有道理的。 模块化之后如何交互,就是解决依赖的问题呢,spring的方式现在几乎成了标配。但是作者给了一中更好方式,那就是lookup,首先不用写配置文件或注解,更容易mock,支持listener,更动态,而且lookup可以由服务端和客户端的好的通信,当然java6之后可以使用serviceloader。 还说到了解决循环依赖的... (1回应)
2013-02-03 22:27 1人喜欢
模块化 是随着复杂度提高的一种必须,从更高层次解决混乱,提高内聚,更容易维护。 想来spring3之后分成那么多的模块是很有道理的。 模块化之后如何交互,就是解决依赖的问题呢,spring的方式现在几乎成了标配。但是作者给了一中更好方式,那就是lookup,首先不用写配置文件或注解,更容易mock,支持listener,更动态,而且lookup可以由服务端和客户端的好的通信,当然java6之后可以使用serviceloader。 还说到了解决循环依赖的一个解决办法,我的理解就是把其中一个依赖抽象出来成为新的一层,让其中一个依赖第三方,文中也说了结合lookup很好的实现这个。 文中说了lookup和spring的上下文是可以很好的结合起来用的。 还说了一个例子,基于类的api比基于接口的api有更好的控制作用。 使用lookup的工厂类的时候,基本是代表滥用了lookup,因为这样缺少了环境信息,解决的办法是在构造方法中传入参数,但是参数多个时候会比较复杂。 第8章主要说了设计api和spi的不同,一个基于功能,一个基于实现和扩展。 一个很好的原则是api和spi尽量分开,一个是接口包,一个是实现包,如果不分开的话,也就是继承和代理共存的情况下,基本要通过反射才能很好的处理。
1回应 2013-02-03 22:27 -
方法优于字段,首先方法有更大的修改的灵活性,而且java在字段的限制更多,在兼容性方面, 工厂方法优于构造方法,工厂方法不一定生成对象,而且生产的对象可以是子类对象。而且工厂方法有更大的灵活性。 api很大的一个原则是让所有的内容不可更改,所以可以看到fianl类大显身手了。 通过友元去访问对象,即组合有余继承。这里的友元可以不一定需要对应的字段,可以由方法生成。 赋予对象创建者更多的权利,这个其实没怎么看懂...
2013-02-03 09:07 1人喜欢
方法优于字段,首先方法有更大的修改的灵活性,而且java在字段的限制更多,在兼容性方面, 工厂方法优于构造方法,工厂方法不一定生成对象,而且生产的对象可以是子类对象。而且工厂方法有更大的灵活性。 api很大的一个原则是让所有的内容不可更改,所以可以看到fianl类大显身手了。 通过友元去访问对象,即组合有余继承。这里的友元可以不一定需要对应的字段,可以由方法生成。 赋予对象创建者更多的权利,这个其实没怎么看懂,其中的一个例子有点意思,依赖于一个中间对象config,可以在这个config上做文章。 避免深层次的继承,继承很大程度是为了增强,说白了就是复用代码,但是api的本质并不是复用代码,如果确实api的目的的复用代码,那么要做好子类化的准备。 第六章 面向接口而不是不是面向实现 首先这里的接口是抽象的意思,不是java的interface。 接口的一个好处是更容易控制稳定性,人们很难再接口上做文章。 如果api可能会要修改,那么用final类吧,保证稳定和易于修改。 想要代码复用,特别是复用一些抽象方法,用抽象类。 其中还看到接口多继承的好处,可以减少内存的使用,不用接口用友元的方式的话会增加对象,增加内存的使用。
回应 2013-02-03 09:07 -
这章说了api的兼容性,源代码基本的,二进制级别的。其实在这两个层次保证东都是很困难的,其中一个例子说明了假如不是一起编译,不同类的final变量会是不一样的。 设计api的一个重要的地方是面向用例,这样才有更加符合实际的api api按规范设计很重要,想当然的按功能去设计,偏差会不少。 api的评审,其实能通过一些大众化的规范性的原则,这时就有不错的成效了。 api的生命周期,是需要不断去维护,从不完善阶段到完善。而且...
2013-01-31 23:03 1人喜欢
这章说了api的兼容性,源代码基本的,二进制级别的。其实在这两个层次保证东都是很困难的,其中一个例子说明了假如不是一起编译,不同类的final变量会是不一样的。 设计api的一个重要的地方是面向用例,这样才有更加符合实际的api api按规范设计很重要,想当然的按功能去设计,偏差会不少。 api的评审,其实能通过一些大众化的规范性的原则,这时就有不错的成效了。 api的生命周期,是需要不断去维护,从不完善阶段到完善。而且一个观点,不少api来源一个程序员发现另外一个写了个不错的功能,自己这边用的上,从而催生api。 最后说的逐步完善的原则,说了软件设计的混乱性,从开始的结构关系良好,到后来的盘根交错,以及可能任何一个人都不能完全理清关系。然后可能推倒从来,但从来还是那个循环。所以一颗可逐步完善的设计很重要,以后的重构也很重要。
回应 2013-01-31 23:03 -
SuperSnail (慢,再慢一点……)
-
杨博 (╭ ̄▽ ̄)╭ 豆邮(1)
在工作时,如果不需要深入了解很多内容时也能完成任务,那么在这种情况下做出来的系统就更可靠。 这段话正确。但还有另一半的话,原文没有讲。这是敏捷开发方式所提倡的:“了解的同事工作的细节越多,做出来的系统就越靠谱。” 软件不可靠的根源就在于软件要求程序员了解其细节才能维护,然而程序员往往并不了解其细节。有两个思路来解决:a.良好的API降低对程序员的要求(本书强调的);b.通过流程规范迫使程序员去了解细节(...2011-09-28 13:02 1人喜欢
-
现代软件大都基于大型组件进行组装,先安装web server和DB,然后开始着手写代码。 整个方案像推土机的工作方式一样。 这种方式优点在于,参与者(如程序员)不完全了解系统,也能得到不错的结果。 对于日益庞大的应用程序,每个人只应了解应用程序的一部分,也能完成程序的开发。 理性主义,经验主义,及无绪。 无绪(cluelessness) 理解暂时分为:浅层理解和深层理解 大多数情况下我们需要浅层理解。 针对性无绪即表示 大部分...
2012-04-10 22:08
-
SuperSnail (慢,再慢一点……)
-
ZFenng (追求技术又学习管理的IT人)
api公开的内容: 1 公开方法优于字段。除了final等基本类型,不变对象,枚举对象以外,其它字段均不能公开。用方法控制时能增加其它额外行为,并且能加强兼容性。如能将方法从子类转移到父类中,但字段则不能做到二进制兼容。 2 工厂方法优于构造函数。new的对象一定是类的实例而不能是子类,并且总是构造一个全新的对象。 3 让内容不可更改。比如让类不能被继承,否则今后也要支持由于继承后的使用方法。以及避免过多暴露set...2013-05-06 16:42
0 有用 黄云斌 2013-03-03
这本书很多地方还是有些超出我的知识范围。希望以后能重新读一遍。这本书真的很好,而且我也花了太多的时间去读。平均下来估计一个小时不到30页。
0 有用 JLming6 2013-06-19
太跟NetBeans相关了,很多地方没太读懂。
4 有用 第五象限 2013-06-03
总的来说框架可以这样看,一来是为了规范团队开发的,相同的命名规范,相同的接口,相同的实现方式,二来是为了分离部分底层逻辑的,直接使用更加抽象的思维进行开发,忽略底层的io,数据库,类库加载之类的操作,基本上可以说是为了实现敏捷开发,三来么可以说是留人之策,把你培训成代码工人,你想走也无处可去,毕竟依靠框架做项目的开发人员待遇都不会很高的,除非你转去做架构之类的,但是这些东西你在使用框架的时候是根本... 总的来说框架可以这样看,一来是为了规范团队开发的,相同的命名规范,相同的接口,相同的实现方式,二来是为了分离部分底层逻辑的,直接使用更加抽象的思维进行开发,忽略底层的io,数据库,类库加载之类的操作,基本上可以说是为了实现敏捷开发,三来么可以说是留人之策,把你培训成代码工人,你想走也无处可去,毕竟依靠框架做项目的开发人员待遇都不会很高的,除非你转去做架构之类的,但是这些东西你在使用框架的时候是根本接触不到的,做久了员工也就不怎么想跳了,留住50%的老员工绝对没有什么问题,四来就是新人上手快,即使这娃再怎么笨,框架良好的封装,最小化的用户接口也能让他基本上不怎么犯错,即便不了解深层的原理也可以实现很多功能,这样一来降低了成本(人力资源成本),毕竟新人的薪水都不怎么高的说,除非是天才型的 (展开)
1 有用 流沙 2017-02-18
更加偏向于API的设计
0 有用 何一涛 2019-07-13
这本书主要教程序员怎么设计 API 。作者表达中包含很多隐喻以及举例多与 Netbean相关,加之翻译的原因,很多细节没看明白,后面有机会再翻阅一遍。
0 有用 尹小少爷 2020-03-26
我现在都记住那句话,大概是,api一旦被定义,就如恒星一样,
0 有用 何一涛 2019-07-13
这本书主要教程序员怎么设计 API 。作者表达中包含很多隐喻以及举例多与 Netbean相关,加之翻译的原因,很多细节没看明白,后面有机会再翻阅一遍。
0 有用 Acer 2019-04-21
0 有用 aimager 2019-04-09
以为是讲框架设计的,其实是讲API设计的
0 有用 eddyzhou 2017-06-01
这书写的太催眠了,以至于距离第一次翻这书已经过去了好几年