在面向对象编程中，好的系统，都无法离开下面六大设计原则。这篇文章主要是整理了一下我自己对六大设计原则的一些理解。

单一职责原则

理解： 简单的说就是功能模块的划分需要单一，即一个接口需要只为一件事情服务

举例： 用户基本信息(UserDO)和用户操作(UserService)依据功能的不同划分开，即一个负责用户信息，一个负责用户操作。

分析：

• 一个功能模块的改动不至于影响其他的功能模块
• 上层应用对于依赖清晰，不同的模块依赖不同的接口
• 底层的修改减少对上层依赖的影响，修改A模块不会影响到依赖B模块的上层接口

里氏替换原则

理解： 父类能够完成的工作，可以直接替换成子类并且不应该会出现异常。

举例： 上层接口依赖底层的父类A来完成某项工作，但是实际上却注入传入的却是A的子类的引用。

分析：

• 上层可以依赖底层的接口或者父类，而实际传入确实接口的实现或者子类
• 上层可以不需要关心底层的具体实现是哪个，因为任何一个实现都能够完成这项工作，从而做到解耦合。

依赖倒置原则

理解：

• 上层不应该依赖底层的细节，而应该依赖抽象。
• 抽象要依赖抽象，不应该依赖细节。
• 抽象即接口或者父类。

举例：

• spring IOC，上层依赖的类型实际上是底层的接口。
• 类型定义为接口类型，即List list ＝ new ArrayList()。

分析：

• 面向对象的正常依赖顺序是上层依赖一个具体的对象，因为你所需要的行为都是有一个具体的对象来提供的。
• 依赖反转则是不去依赖具体的实现，而是去依赖接口。
• 配合上里氏替换原则和java运行时类型，可以做到底层的实现对上层透明，上层不需要关心运行时的实现类是A还是B，底层的变更不需要上层同时修改。

接口隔离原则

理解： 一个接口提供的功能不应该过于臃肿

举例：

• 接口A提供给内部系统修改用户信息。
• 接口B提供给外部系统修改用户信息。

分析：

• 业务隔离
• 如果内外部系统都用同一套方法，会使得业务纠缠在一起，任何一方的需求变动都影响另一方。
• 如果A B接口合并成一个接口，则会产生误用的风险。

迪米特法则

理解： 最小依赖，即只使用自己依赖的（成员变量或者方法传参，jdk自带的类不算），而不应该直接使用自己没依赖的。

举例： 略，只使用类变量，成员变量，方法入参都算使用案例。

分析:

• 依赖关系清晰，上层不需要依赖过多的底层类型，底层的修改仅可能影响到直接依赖他的方法。
• 缺点，可能会造成很多的中间类，所以实际应用时候可以变通着来，个人觉得中间类型最多两个即可。

开闭原则

理解：

• 面向对象设计原则的最高思想，对扩展开放，对修改关闭。
• 上面的五个设计规则都是为了实现这个原则而来的。
• 更加单一的功能，更加隔离的业务，依赖抽象，减少不必要的依赖，都可以帮助我们在增加／修改需求时减少修改代码，而通过扩展来完成。