Solid设计原则

1 S单一职责原则（Single responsibility principle，SPR）

定义：一个类或者模块只负责一个职责（功能）

也就是说单个类不应该大而全，设计的粒度要小，类的职责单一，降低阅读的复杂性

宽泛可量化的标准：单类的代码行数不超过200行，方法和属性个数不要超过10个

注意：粒度不是越小越好，而是适中，满足业务的当前发展即可，随着业务不断发展而不断重构拆分

2 O开闭原则（Open Closed Principle，OCP）

定义：软件实体应当对扩展开放，对修改关闭

设计模式里大部分模式都是为了解决扩展性的问题存在的

添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法

等）

注意：对扩展开放是为了应对变化（新的需求），对修改关闭是为了保证已有代码的稳定性。例如增加属性，可以是修改类已有代码，而不是新增类，但只要没有破坏原有代码的正常运行，就是一个合格的改动。不是一定要扩展代替修改，而是为了避免影响已有的代码逻辑

3 L里氏替换原则（Liskov Substitution Principle，LSP）

定义：子类能够替换程序中的父类对象出现的任何地方

要求就是子类可以扩展父类的功能，但不能改变父类原有的功能（不能重写），在代码里子类能随时替换父类。

从接口或父类的角度出发，顶层的接口/父类要设计的足够通用，并且可扩展，不要为子类或实现类指定实现逻辑，尽量只定义接口规范以及必要的通用性逻辑，这样实现类就可以根据具体场景选择具体实现逻辑而不必担心破坏顶层的接口规范。

从子类或实现类角度出发，底层实现不应该轻易破坏顶层规定的接口规范或通用逻辑

4 I接口隔离原则（Interface Segregation Principle，ISP）

定义：客户端不应该依赖它不需要的接口类

客户端：可以理解为接口的调用者或者使用者  

实现接口的类中，有多余的方法时，需要将接口进行拆分

5 D依赖倒置原则（Dependency Inversion Principle，DIP）

定义：面向接口编程，程序要依赖于抽象接口，不要依赖于具体实现

即对于变量或者传参数，尽量使用抽象类，或者接口，降低耦合

总的来说：

1 使用组合（拥有）代替继承

2 面向接口编程，变量和传递参数使用抽象

3 类或接口的设计应该单一