软件框架设计的艺术
第一部分 理论与理由
第1章 软件开发的艺术
1.1 理性主义，经验主义以及无绪
1.2 软件的演变过程
1.3 大型软件
1.4 漂亮，真理和优雅
1.5 更好的无绪
第2章 设计api的动力之源
2.1 分布式开发
2.2 模块化应用程序
查看完整
第1章 软件开发的艺术
1.1 理性主义，经验主义以及无绪
1.2 软件的演变过程
1.3 大型软件
1.4 漂亮，真理和优雅
1.5 更好的无绪
第2章 设计api的动力之源
2.1 分布式开发
2.2 模块化应用程序
查看完整
Jaroslav Tulach，NetBeans的创始人，也是NetBeans项目最初的架构师。有着丰富的项目开发经验，一直致力于如何提高开发人员的设计技巧，从而保证了NetBeans项目的成功。
王磊，工学学士及硕士。2006年起任职于普元公司，一直担任普元公司主任架构师。同时是自由软件Aquarius ORM Studio的作者。
朱兴，软件工程师。一直从事软件研发工作，熟悉Java、Eclipse插件开发、API设计等相关技术。
王磊，工学学士及硕士。2006年起任职于普元公司，一直担任普元公司主任架构师。同时是自由软件Aquarius ORM Studio的作者。
朱兴，软件工程师。一直从事软件研发工作，熟悉Java、Eclipse插件开发、API设计等相关技术。
《软件框架设计的艺术》帮助你解决api 设计方面的问题，共分3 个部分，分别指出学习api 设计是需要进行科学的训练的、java 语言在设计方面的理论及设计和维护api 时的常见情况，并提供了各种技巧来解决相应的问题。
《软件框架设计的艺术》作者是netbeans 的创始人，也是netbeans 项目最初的架构师。相信在api 设计中遇到问题时，本书将不可或缺。
《软件框架设计的艺术》适用于软件设计人员阅读。
《软件框架设计的艺术》作者是netbeans 的创始人，也是netbeans 项目最初的架构师。相信在api 设计中遇到问题时，本书将不可或缺。
《软件框架设计的艺术》适用于软件设计人员阅读。
第一部分 理论与理由
第1章 软件开发的艺术
1.1 理性主义，经验主义以及无绪
1.2 软件的演变过程
1.3 大型软件
1.4 漂亮，真理和优雅
1.5 更好的无绪
第2章 设计api的动力之源
2.1 分布式开发
2.2 模块化应用程序
2.3 交流互通才是一切
2.4 经验主义编程方式
2.5 开发第一个版本通常比较容易
第3章 评价api好坏的标准
3.1 方法和字段签名
3.2 文件及其内容
3.3 环境变量和命令行选项
3.4 文本信息也是api
3.5 协议
3.6 行为
3.7 国际化支持和信息国际化
3.8 api的广泛定义
3.9 如何检查api的质量
3.9.1 可理解性
3.9.2 一致性
3.9.3 可见性
3.9.4 简单的任务应该有简单的方案
3.9.5 保护投资
第4章 不断变化的目标
4.1 第一个版本远非完美
4.2 向后兼容
4.2.1 源代码兼容
4.2.2 二进制兼容
4.2.3 功能兼容--阿米巴变形虫效应
4.3 面向用例的重要性
4.4 api设计评审
4.5 一个api的生命周期
4.6 逐步改善
第二部分 设计实战
第5章 只公开你要公开的内容
5.1 方法优于字段
5.2 工厂方法优于构造函数
5.3 让所有内容都不可更改
5.4 避免滥用setter方法
5.5 尽可能通过友元的方式来公开功能
5.6 赋予对象创建者更多权利
5.7 避免暴露深层次继承
第6章 面向接口而非实现进行编程
6.1 移除方法或者字段
6.2 移除或者添加一个类或者接口
6.3 向现有的继承体系中添加一个接口或者类
6.4 添加方法或者字段
6.5 java中接口和类的区别
6.6 弱点背后的优点
6.7 添加方法的另一种方案
6.8 抽象类有没有用呢
6.9 要为增加参数做好准备
6.10 接口vs.类
第7章 模块化架构
7.1 模块化设计的类型
7.2 组件定位和交互
7.3 编写扩展点
7.4 循环依赖的必要性
7.5 满城尽是lookup
7.6 lookup的滥用
第8章 设计api时要区分其目标用户群
8.1 c和java语言中如何定义api和spi
8.2 api演进不同于spi演进
8.3 java.io.writer这个类从jdk 1.4到jdk 5的演进
8.4 合理分解api
第9章 牢记可测试性
9.1 api设计和测试
9.2 规范的光环正在褪去
9.3 好工具让api设计更简单
9.4 兼容性测试套件
第10章 与其他api协作
10.1 谨慎使用第三方api
10.2 只暴露抽象内容
10.3 强化api的一致性
10.4 代理和组合
10.5 避免api的误用
10.6 不要滥用javabeans那种监听器机制
第11章 api具体运行时的一些内容
11.1 不要冒险
11.2 可靠性与无绪
11.3 同步和死锁
11.3.1 描述线程模型
11.3.2 java monitors中的陷阱
11.3.3 触发死锁的条件
11.3.4 测试死锁
11.3.5 对条件竞争进行测试
11.3.6 分析随机故障
11.3.7 日志的高级用途
11.3.8 使用日志记录程序控制流程
11.4 循环调用的问题
11.5 内存管理
第12章 声明式编程
12.1 让对象不可变
12.2 不可变的行为
12.3 文档兼容性
第三部分 日常生活
第13章 极端的意见有害无益
13.1 api必须是漂亮的
13.2 api必须是正确的
13.3 api应该尽量简单
13.4 api必须是高性能的
13.5 api必须绝对兼容
13.6 api必须是对称的
第14章 api设计中的矛盾之处
14.1 api设计中的自相矛盾
14.2 背后隐藏的工作
14.3 不要害怕发布一个稳定的api
14.4 降低维护费用
第15章 改进api
15.1 让有问题的类库重新焕发活力
15.2 自觉地升级与无意识地被迫升级
15.3 可选的行为
15.4 相似api的桥接和共存
第16章 团队协作
16.1 在提交代码时进行代码评审
16.2 说服开发人员为他们的api提供文档
16.3 尽职尽责的监控者
16.4 接受api的补丁
第17章 利用竞赛游戏来提升api设计技巧
17.1 概述
17.2 第一天
17.2.1 非public类带来的问题
17.2.2 不可变性带来的问题
17.2.3 遗漏实现的问题
17.2.4 返回结果可能不正确的问题
17.2.5 第一天的解决方案
17.3 第二天
17.3.1 我想修正犯下的错误
17.3.2 第二天的解决方案
17.4 第三天：评判日
17.5 也来玩下这个游戏吧
第18章 可扩展visitor模式的案例
18.1 抽象类
18.2 为改进做好准备
18.3 默认的遍历
18.4 清楚地定义每个版本
18.5 单向改进
18.6 使用接口时的数据结构
18.7 针对用户和开发商的visitor模式
18.8 三重调度
18.9 visitor模式的圆满结局
18.10 语法小技巧
第19章 消亡的过程
19.1 明确版本的重要性
19.2 模块依赖的重要性
19.3 被移除的部分需要永久保留吗
19.4 分解庞大的api
第20章 未来
20.1 原则性内容
20.2 无绪长存
20.3 api设计方法论
20.4 编程语言的演变
20.5 教育的作用
20.6 共享
参考书目
^ 收 起
第1章 软件开发的艺术
1.1 理性主义，经验主义以及无绪
1.2 软件的演变过程
1.3 大型软件
1.4 漂亮，真理和优雅
1.5 更好的无绪
第2章 设计api的动力之源
2.1 分布式开发
2.2 模块化应用程序
2.3 交流互通才是一切
2.4 经验主义编程方式
2.5 开发第一个版本通常比较容易
第3章 评价api好坏的标准
3.1 方法和字段签名
3.2 文件及其内容
3.3 环境变量和命令行选项
3.4 文本信息也是api
3.5 协议
3.6 行为
3.7 国际化支持和信息国际化
3.8 api的广泛定义
3.9 如何检查api的质量
3.9.1 可理解性
3.9.2 一致性
3.9.3 可见性
3.9.4 简单的任务应该有简单的方案
3.9.5 保护投资
第4章 不断变化的目标
4.1 第一个版本远非完美
4.2 向后兼容
4.2.1 源代码兼容
4.2.2 二进制兼容
4.2.3 功能兼容--阿米巴变形虫效应
4.3 面向用例的重要性
4.4 api设计评审
4.5 一个api的生命周期
4.6 逐步改善
第二部分 设计实战
第5章 只公开你要公开的内容
5.1 方法优于字段
5.2 工厂方法优于构造函数
5.3 让所有内容都不可更改
5.4 避免滥用setter方法
5.5 尽可能通过友元的方式来公开功能
5.6 赋予对象创建者更多权利
5.7 避免暴露深层次继承
第6章 面向接口而非实现进行编程
6.1 移除方法或者字段
6.2 移除或者添加一个类或者接口
6.3 向现有的继承体系中添加一个接口或者类
6.4 添加方法或者字段
6.5 java中接口和类的区别
6.6 弱点背后的优点
6.7 添加方法的另一种方案
6.8 抽象类有没有用呢
6.9 要为增加参数做好准备
6.10 接口vs.类
第7章 模块化架构
7.1 模块化设计的类型
7.2 组件定位和交互
7.3 编写扩展点
7.4 循环依赖的必要性
7.5 满城尽是lookup
7.6 lookup的滥用
第8章 设计api时要区分其目标用户群
8.1 c和java语言中如何定义api和spi
8.2 api演进不同于spi演进
8.3 java.io.writer这个类从jdk 1.4到jdk 5的演进
8.4 合理分解api
第9章 牢记可测试性
9.1 api设计和测试
9.2 规范的光环正在褪去
9.3 好工具让api设计更简单
9.4 兼容性测试套件
第10章 与其他api协作
10.1 谨慎使用第三方api
10.2 只暴露抽象内容
10.3 强化api的一致性
10.4 代理和组合
10.5 避免api的误用
10.6 不要滥用javabeans那种监听器机制
第11章 api具体运行时的一些内容
11.1 不要冒险
11.2 可靠性与无绪
11.3 同步和死锁
11.3.1 描述线程模型
11.3.2 java monitors中的陷阱
11.3.3 触发死锁的条件
11.3.4 测试死锁
11.3.5 对条件竞争进行测试
11.3.6 分析随机故障
11.3.7 日志的高级用途
11.3.8 使用日志记录程序控制流程
11.4 循环调用的问题
11.5 内存管理
第12章 声明式编程
12.1 让对象不可变
12.2 不可变的行为
12.3 文档兼容性
第三部分 日常生活
第13章 极端的意见有害无益
13.1 api必须是漂亮的
13.2 api必须是正确的
13.3 api应该尽量简单
13.4 api必须是高性能的
13.5 api必须绝对兼容
13.6 api必须是对称的
第14章 api设计中的矛盾之处
14.1 api设计中的自相矛盾
14.2 背后隐藏的工作
14.3 不要害怕发布一个稳定的api
14.4 降低维护费用
第15章 改进api
15.1 让有问题的类库重新焕发活力
15.2 自觉地升级与无意识地被迫升级
15.3 可选的行为
15.4 相似api的桥接和共存
第16章 团队协作
16.1 在提交代码时进行代码评审
16.2 说服开发人员为他们的api提供文档
16.3 尽职尽责的监控者
16.4 接受api的补丁
第17章 利用竞赛游戏来提升api设计技巧
17.1 概述
17.2 第一天
17.2.1 非public类带来的问题
17.2.2 不可变性带来的问题
17.2.3 遗漏实现的问题
17.2.4 返回结果可能不正确的问题
17.2.5 第一天的解决方案
17.3 第二天
17.3.1 我想修正犯下的错误
17.3.2 第二天的解决方案
17.4 第三天：评判日
17.5 也来玩下这个游戏吧
第18章 可扩展visitor模式的案例
18.1 抽象类
18.2 为改进做好准备
18.3 默认的遍历
18.4 清楚地定义每个版本
18.5 单向改进
18.6 使用接口时的数据结构
18.7 针对用户和开发商的visitor模式
18.8 三重调度
18.9 visitor模式的圆满结局
18.10 语法小技巧
第19章 消亡的过程
19.1 明确版本的重要性
19.2 模块依赖的重要性
19.3 被移除的部分需要永久保留吗
19.4 分解庞大的api
第20章 未来
20.1 原则性内容
20.2 无绪长存
20.3 api设计方法论
20.4 编程语言的演变
20.5 教育的作用
20.6 共享
参考书目
^ 收 起
Jaroslav Tulach，NetBeans的创始人，也是NetBeans项目最初的架构师。有着丰富的项目开发经验，一直致力于如何提高开发人员的设计技巧，从而保证了NetBeans项目的成功。
王磊，工学学士及硕士。2006年起任职于普元公司，一直担任普元公司主任架构师。同时是自由软件Aquarius ORM Studio的作者。
朱兴，软件工程师。一直从事软件研发工作，熟悉Java、Eclipse插件开发、API设计等相关技术。
王磊，工学学士及硕士。2006年起任职于普元公司，一直担任普元公司主任架构师。同时是自由软件Aquarius ORM Studio的作者。
朱兴，软件工程师。一直从事软件研发工作，熟悉Java、Eclipse插件开发、API设计等相关技术。
《软件框架设计的艺术》帮助你解决api 设计方面的问题，共分3 个部分，分别指出学习api 设计是需要进行科学的训练的、java 语言在设计方面的理论及设计和维护api 时的常见情况，并提供了各种技巧来解决相应的问题。
《软件框架设计的艺术》作者是netbeans 的创始人，也是netbeans 项目最初的架构师。相信在api 设计中遇到问题时，本书将不可或缺。
《软件框架设计的艺术》适用于软件设计人员阅读。
《软件框架设计的艺术》作者是netbeans 的创始人，也是netbeans 项目最初的架构师。相信在api 设计中遇到问题时，本书将不可或缺。
《软件框架设计的艺术》适用于软件设计人员阅读。
比价列表
