如何写出满足单元测试的代码-（SOLID）设计原则

1. 最开始只写粗框架，必要时会加上为了让自己理清逻辑的注释。等框架搭完后再完善日志、注释和异常保护等
2. 函数设计符合单元测试要求，就是写出的代码要能够方便的实现单元测试，先来看一下单元测试的要求：

良好的单元测试的特点

1. 代码简洁清晰
   我们会针对一个单元写多个测试用例，因此我们希望用尽量简洁的代码覆盖到所有的测试用例。
2. 可读性强
   测试方法的名称应该直截了当地表明测试内容和意图，如果测试失败了，我们可以简单快速地定位问题。通过良好的单元测试，我们可以无需通过debug，打断点的方式来修复bug。
3. 可靠性强
   单元测试只在所测的单元中真的有bug才会不通过，不能依赖任何单元外的东西，例如全局变量、环境、配置文件或方法的执行顺序等。当这些东西发生变化时，不会影响测试的结果。
4. 执行速度快
   通常我们每一次打包都会运行单元测试，如果速度非常慢，影响效率，也会导致更多人在本地跳过测试。
5. 只测试独立单元
   单元测试和集成测试的目的不同，单元测试应该排除外部因素的影响。

   那函数该如何设计来满足单元测试呢，就要依靠设计原则来实现了：

六大设计原则(SOLID)>
Single Responsibility Principle：单一职责原则
Open Closed Principle：开闭原则
Liskov Substitution Principle：里氏替换原则
Law of Demeter：迪米特法则 Interface
Segregation Principle：接口隔离原则
Dependence Inversion Principle：依赖倒置原则

把这六个原则的首字母联合起来（两个 L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。

六大设计原则之单一职责原则（SRP）（Single Responsibility Principle） 一个类应该只有一个发生变化的原因
There should never be more than one reason for a class to change.

六大设计原则之开闭原则（OCP）（Open Closed Principle） 一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭
Software entities like classes, modules and functions should be open
for extension but closed for modification

六大设计原则之里氏替换原则（LSP）（Liskov Substitution Principle）
所有引用基类的地方必须能透明地使用其子类的对象 Functions that use use pointers or references
to base classes must be able to use objects of derived classes without knowing it.

六大设计原则之迪米特法则（LOD）（Law of Demeter） 只与你的直接朋友交谈，不跟“陌生人”说话 Talk only to
your immediate friends and not to strangers
其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

六大设计原则之接口隔离原则（ISP）（Interface Segregation Principle）
1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上。 Clients should not be forced to depend upon
interfaces that they don`t use. The dependency of one class to another
one should depend on the smallest possible.
注：该原则中的接口，是一个泛泛而言的接口，不仅仅指Java中的接口，还包括其中的抽象类。

六大设计原则之依赖倒置原则（Dependence Inversion Principle）
1、上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2、抽象不应该依赖于细节，细节应该依赖于抽象。 High level modules
should not depend upon low level modules. Both should depend upon
abstractions. Abstractions should not depend upon details. Details
should depend upon abstractions.