A-Philosophy-of-Software-Design

《软件设计哲学》

目录

前言

1引言

1.1如何使用本书

2复杂性的本质

2.1定义复杂性

2.2复杂性的症状

2.3复杂性的原因

2.4复杂性是递增的

2.5结论

3工作守则还不够

3.1战术编程

3.2战略规划

3.3投资多少？

3.4初创公司和投资

3.5结论

4个模块应该很深

4.1模块化设计

4.2界面中有什么？

4.3抽象

4.4深层模块

4.5浅模块

4.6 Classitis

4.7示例：Java和Unix I / O.

4.8结论

5信息隐藏（和泄漏）

5.1信息隐藏

5.2信息泄露

5.3时间分解

5.4示例：HTTP服务器

5.5示例：类太多了

5.6示例：HTTP参数处理

5.7示例：HTTP响应中的默认值

5.8隐藏在类中的信息

5.9太过分了

5.10结论

6个通用模块更深入

6.1使课程有点通用

6.2示例：为编辑器存储文本

6.3更通用的API

6.4一般性导致更好的信息隐藏

6.5问自己的问题

6.6结论

7个不同的层，不同的抽象

7.1传递方法

7.2接口复制何时可以？

7.3装饰

7.4接口与实现

7.5传递变量

7.6结论

8向下拉复杂性

8.1示例：编辑器文本类

8.2示例：配置参数

8.3太过分了

8.4结论

9更好地在一起还是更好？

9.1如果共享信息，请汇集在一起

9.2如果它将简化界面，汇集在一起

9.3汇集在一起以消除重复

9.4单独的通用和专用代码

9.5示例：插入光标和选择

9.6示例：用于记录的单独类

9.7示例：编辑器撤消机制

9.8分裂和连接方法

9.9结论

10定义存在的错误

10.1为什么例外会增加复杂性

10.2太多例外

10.3定义错误不存在

10.4示例：Windows中的文件删除

10.5示例：Java子串方法

10.6掩盖异常

10.7异常聚合

10.8刚崩溃？

10.9设计特殊情况不存在

10.10太过分了

10.11结论

11设计两次

12为什么写评论？ 四个借口

12.1好的代码是自我记录的

12.2我没时间写评论

12.3评论过时并变得具有误导性

12.4我看到的所有评论都毫无价值

12.5写得好的评论的好处

13评论应该描述代码中不明显的事情

13.1选择约定

13.2不要重复代码

13.3较低级别的注释增加了精度

13.4更高层次的评论增强了直觉

13.5接口文档

13.6实施意见：什么和为什么，而不是如何

13.7跨模块设计决策

13.8结论

13.9第13.5节中的问题答案

14选择名称

14.1示例：错误的名称会导致错误

14.2创建图像

14.3名称应该准确

14.4始终使用名称

14.5不同的意见：去风格指南

14.6结论

15首先写下评论

15.1延迟评论是不好的评论

15.2首先写下评论

15.3评论是一种设计工具

15.4早期评论是有趣的评论

15.5早期评论是否昂贵？

15.6结论

16修改现有代码

16.1保持战略性

16.2维护注释：将注释保留在代码附近

16.3注释属于代码，而不是提交日志

16.4维护评论：避免重复

16.5维护注释：检查差异

16.6更高级别的注释更容易维护

17一致性

17.1一致性的例子

17.2确保一致性

17.3太过分了

17.4结论

18代码应该是显而易见的

18.1使代码更加明显的事情

18.2使代码不那么明显的事情

18.3结论

19软件趋势

19.1面向对象的编程和继承

19.2敏捷开发

19.3单元测试

19.5设计模式

19.6吸气鬼和二传手

19.7结论

20性能设计

20.1如何考虑绩效

20.2修改前的测量

20.3围绕关键部分进行设计

20.4一个例子：RAMCloud缓冲区

20.5结论

21结论

v指数

设计原则摘要

红旗总结