🧘‍♂️
软件设计哲学
  • 0️⃣序章
    • 软件设计哲学（中文版）
    • 译者序
    • 前言
  • 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 类炎
    • 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.1 为什么异常情况会增加复杂性
    • 10.2 太多的异常
    • 10.3 将错误定义为不存在的
    • 10.4 例子：在Windows中删除文件
    • 10.5 例子：Java子串方法
    • 10.6 屏蔽异常
    • 10.7 异常聚合
    • 10.8 就崩溃吧？
    • 10.9 将特殊情况设计为不存在的
    • 10.10 走得太远
    • 10.11 小结
  • 1️第十一章 设计两次
    • 设计两次
  • 2️第十二章 为什么要写注释？四个借口
    • 为什么要写注释？四个借口
    • 12.1 好的代码是自文档化的
    • 12.2 我没有时间写注释
    • 12.3 注释会过时并变得具有误导性
    • 12.4 我所看到的注释都是毫无价值的
    • 12.5 良好注释的好处
  • 3️第十三章 注释应该描述那些在代码中不明显的东西
    • 注释应该描述那些在代码中不明显的东西
    • 13.1 挑选约定
    • 13.2 不要重复代码
    • 13.3 更低层次的注释增加了精确性
    • 13.4 更高层次的注释增强直觉
    • 13.5 接口文档
    • 13.6 实现注释：是什么和为什么，而不是怎么做
    • 13.7 跨模块设计决策
    • 13.8 小结
    • 13.9 对第13.5节的问题的回答
  • 4️第十四章 选择名称
    • 选择名称
    • 14.1 例子：不好的名称会导致bug
    • 14.2 建立一个形象
    • 14.3 名称应当准确
    • 14.4 一致地使用名称
    • 14.5 一种不同的意见：Go风格指南
    • 14.6 小结
  • 5️第十五章 先写注释
    • 先写注释
    • 15.1 迟到的注释不是好注释
    • 15.2 先写注释
    • 15.3 注释是一种设计工具
    • 15.4 早期的注释是有趣的注释
    • 15.5 早期注释是否成本过高？
    • 15.6 小结
  • 6️第十六章 修改现有代码
    • 修改现有代码
    • 16.1 保持战略性
    • 16.2 维护注释：让注释靠近代码
    • 16.3 注释属于代码，而不是提交日志
    • 16.4 维护注释：避免重复
    • 16.5 维护注释：检查差异
    • 16.6 更高层的注释更容易维护
  • 7️第十七章 一致性
    • 一致性
    • 17.1 一致性的例子
    • 17.2 确保一致性
    • 17.3 走得太远
    • 17.4 小结
  • 8️第十八章 代码应当易于理解
    • 代码应当易于理解
    • 18.1 使代码更易于理解的东西
    • 18.2 使代码更不易于理解的东西
    • 18.3 小结
  • 9️第十九章 软件发展趋势
    • 软件发展趋势
    • 19.1 面向对象的编程和继承
    • 19.2 敏捷开发
    • 19.3 单元测试
    • 19.4 测试驱动的开发
    • 19.5 设计模式
    • 19.6 Getters and setters
    • 19.7 小结
  • 0️第二十章 为性能而设计
    • 为性能而设计
    • 20.1 如何思考性能问题
    • 20.2 修改前的测量
    • 20.3 围绕关键路径进行设计
    • 20.4 一个例子：RAMCloud缓冲区
    • 20.5 小结
  • 🔚第21章 总结
    • 总结
  • #️⃣附录
    • 设计原则摘要
    • 危险信号摘要
    • 关于作者
    • 作者/译者
Powered by GitBook
On this page
  1. 第八章 下拉复杂性

8.4 小结

在开发一个模块时，寻找机会让自己吃一点额外的苦头，让用户少吃点苦头。

Previous8.3 走得太远Next在一起更好还是分开更好？

Last updated 2 years ago

8️⃣