对于一个研发工程师，一定要有一个好的设计思维。
熟悉面向对象的原则，能有利于设计，又有利于测试。如果不成熟的设计，也能实现一些理想的功能，但是对于异常情况的模拟测试很难实现，不能实现产品化。
单一职责（SRP）
定义
每个类或者模块都应该有一个单一职责，并且该职责应由这个类或模块完全封装起来。
职责的变化：
职责的界定会根据类的试用场景界定，当场景变化时需要对类职责进行重新划分。也可以说职责是对于需求的满足，职责层次性来源于需求层次性。
如果一个类承担过多的职责，就等于将这些职责都耦合在一起，任何一个职责的变化都可能造成一个类的变化，也可能引起其他职责的变化。这种耦合导致系统的脆弱性。
软件工程中耦合（Coupling）表示两个子系统（或类）之间的关联程度，当一个子系统（或类）发生变化时对另一个子系统（或类）的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。
开闭原则（OCP）
定义
软件中的实体（类、模板、函数等）应该对扩展是开放的，但是对于修改是封闭的，即开放-封闭原则。
为了使我们的代码有更高的兼容性？（不知道用的词对不对）就是新增一个新的需求的时候，我们不用对已编写的代码进行修改，只用新增一部分代码就可以满足新的需求。
OCP实现的关键在于“抽象”，面向抽象编程。
我们将可变化的点进行“抽象”，“抽象”的变化用“具体实现”来体现，这样就表现的是对“抽象”封闭，对“实现”开放。
修改（How to do）
扩展（What to do）
严格的符合OCP是非常困难的，对于一些之前预测好的变化没有发生过，就称为过度设计。
我们只对当前业务频繁变化的点进行抽象就行，不能抽象所有业务。
里氏替换原则（LSP）
定义
子类必须能完全替换父类，在使用者层次上，子类不能有多于父类的职责。
子类一定不能对父类的行为进行限制
基于正方形是特殊矩形假设将正方形定位为矩形的子类的行为就违反了以上原则，正方形设置长和宽行为限制了矩形的行为设置长和宽的行为（正方形长、宽必须相等）
接口隔离原则 （ISP）
定义
ISP 承认存在一些对象，他们确实不需要内聚的接口，但是 ISP 建议客户程序不应该看到他们作为一个单一的类存在。相反，客户程序看到的应该是多个具有内聚接口的抽象基类。
多个特定客户端接口要好于一个宽泛用途的接口。
一个对外提供的接口尽量只提供一个职责。
依赖翻转原则（DIP）
定义
高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口
抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口
翻转体现在两个点：
1.翻转上下级严格的关系：
上层模块不用依赖于低层模块，也可以依赖于上层抽象接口。
2.翻转接口所有权和定义权：
是上层根据具体的业务定义接口，低层根据业务实现接口定义。而不是低层现有能力抽象为接口供低层使用。从业务驱动的角度这种方式更加合理。
