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