# 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指数 #### 设计原则摘要 #### 红旗总结