2023年阅读笔记3-526互联

八、边界
使用第三方代码
第三方程序包和框架提供者追求普适性，这样就能在多个环境中工作，吸引广泛的用户
我们建议不要将Map（或在边界上的其他接口）在系统中传递，把它保留在类或近亲类中，避免从API中返回边界接口，或将接口作为参数传递给公共API
浏览和学习边界（学习新的第三方代码，需要些学习性测试用例去熟悉它）
学习性测试的好处不只是免费
学习性测试毫无成本，编写测试是获得这些知识（要使用的API）的容易而不会影响其他工作的途径
学习性测试确保第三方程序包按照我们想要的方式工作
使用尚不存在的代码
编写我们想得到的接口，好处之一是它在我们控制之下，有助于保持客户代码更可读，且集中于它该完成的工作（根据需求，编写我方使用的接口,新接入的代码按照这个标准实现功能）
整洁的边界
边界上的改动，有良好的软件设计，无需巨大投入和重写即可进行修改
边界上的代码需要清晰的分割和定义了期望的测试。应该避免我们的代码过多地了解第三方代码中特定信息。依靠你能控制的东西，好过依靠你控制不了的东西，免得日后受它控制
使用ADAPTER模式将我们的接口转换为第三方提供的接口
九、单元测试
TDD三定律
定律一：在编写不能通过的单元测试之前，不可编写生产代码
定律二：只可编写刚好无法通过的单元测试用例，不能编译也不算通过
定律三：只可编写刚好足以通过当前失败测试的生产代码
保持测试整洁
脏测试等同于没测试，测试必须随生产代码的演进而修改，测试越脏，就越难修改
测试代码和生产代码一样重要，它需要被思考、被设计和被照料，它该像生产代码一般保持整洁
如果测试不能保持整洁，你就会失去它们，没有了测试，你就会失去保证生产代码可扩展的一切要素
整洁的测试
三要素：可读性，可读性和可读性，明确、简洁还有足够的表达力
构造-操作-检验（BUILD-OPERATE-CHECK）模式：第一个环节构造测试数据，第二个环节操作测试数据，第三个部分检验操作是否得到期望的结果
守规矩的开发者也将他们的测试代码重构为更加简洁和具有表达力的形式
每个测试一个断言
JUnit中每个测试函数都应该有且只有一个断言语句
每个测试一个概念
尽可能减少每个概念的断言数量，每个测试函数只测试一个概念
F.I.R.S.T
快速（Fast）测试应该快
独立（Independent）测试应该相互独立
可重复（Repeatable）测试应当可在任何环境中重复通过
自足验证（Self-Validating）测试应该有布尔值
及时（Timely）测试应该及时编写
十、类
类的组织
类应该从一级变量列表开始，如果有公共静态变量，应该先出现，然后是私有静态变量，以及实体变量，很少会有公共变量
公共函数应该跟在变量列表之后
保持变量和工具函数的私有性，但并不执着于此
类应该短小
第一规则是类应该短小，第二规则是还要更短小
衡量方法，计算权责（responsibility）
类的名称应当描述其权责，如果无法为某个类命以精确的名称，这个类大概就太长了，类名越含混，该类越有可能拥有过多权责
单一责权原则（SRP）:类和模块应有且只有一条加以修改的理由。
系统应该由许多短小的类而不是少量巨大的类组成，每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为
方法操作的变量越多，就越黏聚到类上，如果一个类的每个变量都被每个方法所使用，则该类具有最大的内聚性
保持函数和参数列表短小的策略，有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时，往往意味着至少有一个类要从大类中挣扎出来。你应当尝试将这些变量和方法分拆到两个或多个类中，让新的类更为内聚
将大函数拆为许多小函数，往往也是将类拆分为多个小类的时机
为了修改而组织
在整洁的系统中，我们对类加以组织，以降低修改的风险
开放-闭合原则（OCP）：类应当对扩展开放，对修改封闭
在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性
部件之间的解耦代表着系统中的元素相互隔离得很好
依赖倒置原则（Dependency Inversion Principle,DIP），类应该依赖于抽象而不是依赖于具体细节