边界
将第三方代码干净利落地整合进自己的代码中
1.避免公共API返回边界接口，或者将边界接口作为参数传递给API。将边界保留在近亲类中。2.不要再生产代码中试验新东西，而是编写测试来理解第三方代码。3.避免我们的代码过多地了解第三方代码中的特定信息。单元测试1.TDD(Test-driven development)三定律
- First Law: You may not write production code until you have written a failing unit test.
- Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
- Third Law: You may not write more production code than is sufficient to pass the currently failing test.
2.保持测试整洁
- 脏测试等同于没测试，测试代码越脏 生产代码越难修改。
- 测试代码和生产代码一样重要。
- 整洁的测试代码最应具有的要素是：整洁性。测试代码中不要有大量重复代码的调用。
3.每个测试一个断言
- 每个测试函数有且仅有一个断言语句。
- 每个测试函数中只测试一个概念。
4.整洁的测试依赖于FIRST规则
- fast: 测试代码应该能够快速运行，因为我们需要频繁运行它。
- independent: 测试应该相互独立，某个测试不应该依赖上一个测试的结果，测试可以以任何顺序进行。
- repeatable: 测试应可以在任何环境中通过
- self-validating: 测试应该有bool值输出，不应通过查看日志来确认测试结果，不应手工对比两个文本文件确认测试结果。
- timely: 及时编写测试代码。单元测试应该在生产代码之前编写，否则生产代码会变得难以测试。
类 1.类的结构组织:
- 公共静态常量
- 私有静态变量
- 私有实体变量
- 公共函数
- 私有工具函数
2.类应该短小
- 对于函数我们计算代码行数衡量大小，对于类我们使用权责来衡量。
- 类的名称应当描述其权责。类的命名是判断类长度的第一个手段，如果无法为某个类命以准确的名称，这个类就太长了。类名包含模糊的词汇，如Processor、Manager、Super，这种现象就说明有不恰当的*权责聚集情况。
- 单一权责原则: 类或者模块应该有一个权责——只有一条修改的理由(A class should have only one reason to change.)。
- 系统应该由许多短小的类而不是少量巨大的类组成。
- 类应该只有少量的实体变量，如果一个类中每个实体变量都被每个方法所使用，则说明该类具有最大的内聚性。创建最大化的内聚类不太现实，但是应该以高内聚为目标，内聚性越高说明类中的方法和变量互相依赖、互相结合形成一个逻辑整体。
- 保持内聚性就会得到许多短小的类。如果你想把一个大函数的某一小部分拆解成单独的函数，拆解出的函数使用了大函数中的4个变量，不必将4个变量作为参数传递到新函数里，仅需将这4个变量提升为大函数所在类的实体变量，但是这么做却因为实体变量的增多而丧失了类的内聚性，更好多做法是让这4个变量拆出来，拥有自己的类。将大函数拆解成小函数往往是将类拆分为小类的时机。
3.为修改而组织(参考书中代码清单10-9、10-10)
- 类应当对扩展开放，对修改封闭(开放闭合原则)
- 在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性。
