扫盲系列 - 面向对象六大原则
单一职责原则 – 优化代码的第一步
- 核心思想：接口或类只提供一种业务实现。
- 宗旨： 每个接口、类的功能，只能用来做专门的事，强调系统内业务职责唯一，避免职责扩散，做到业务统一管理。
- 解释：两个完全不一样的功能就不应该放在一个类中。一个类中应该是一组相关性很高的函数,数据的封装。应根据具体的业务，功能对类进行相应的拆分。
开闭原则 – 让程序更稳定，更灵活
- 核心思想：对扩展开放，对修改关闭。
- 宗旨：在已有系统基础上进行开发，不要对正常运行的代码进行修改操作。需要扩展需求时，通过添加新类或者新代码来实现，对已有代码做到最少修改，甚至是零修改。
- 解释：软件中的对象（类，模块，函数等）应该对于扩展是开放的，但是对于修改是封闭的。当软件需要变化是，我们应该尽量通过扩展的方式来实现变化。而不是通过修改已有的代码来实现。
里氏替换原则 – 构建扩展性更好的系统
- 核心思想：使用父类的地方可以用子类来替换。
- 宗旨：子类尽量不要重写父类或者接口中已经实现的方法，即子类和父类逻辑保持一致性。
- 解释：所有引用基类的地方必须能够透明的使用其子类的对象。通俗的讲只要父类能出现的地方子类就可以出现，并且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。
- 补充：
- 对“开-闭”原则的补充
- 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。
- 尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。
- 子类不应该覆盖父类的非抽象方法（可以重载，但一定要调父类的方法）。
- 核心原理是抽象，抽象又依赖于继承这个特性。
依赖倒置原则 – 让项目拥有变化的能力
- 核心思想：面向抽象编程，即通过接口或者抽象类提供依赖关系。
- 宗旨：指各个业务模块之间依赖关系，通过约定的接口或者抽象类来实现，不涉及具体的实现细节，细节交给具体的实现类来完成。
- 常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。
- 构造注入是指通过构造函数来传入具体类的对象。
- 设值注入是指通过Setter方法来传入具体类的对象。
- 接口注入是指通过在接口中声明的业务方法来传入具体类的对象。
- 解释： 一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的。依赖模块被颠倒了，关键点：
- 高层模块不应该依赖于底层模块，两者都应该依赖其抽象，
- 抽象不应该依赖于细节
- 细节应该依赖于抽象
在 java 语言中
- 抽象就是指接口或者抽象类，两者都不能直接被实例化的;
- 细节就是实现类，实现接口或继承抽象类而产生的类就是细节。
- 高层模块 就是调用端，
- 底层模块就是具体实现类。
模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系通过接口或者抽象类产生。
开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段。
接口隔离原则 – 系统有更高的灵活性
- 核心思想：接口中的方法和属性都是实现类所需要，没有额外无用信息。
- 宗旨：接口的完美复用，接口的内容对于实现来说无冗余代码。
- 解释：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大，臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的放开，让客户端依赖的接口尽可能地小，
- 目的：
- 在使用接口隔离原则时，我们需要注意控制接口的粒度
- 接口不能太小。如果太小会导致系统中接口泛滥，不利于维护；
- 接口也不能太大。太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。
一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。
迪米特原则 – 更好的扩展性
- 核心思想：低耦合，高内聚。
- 宗旨：弱化代码（通常指类）之间的依赖关系。
既已览卷至此，何不品评一二：