架构中设计原则

在使用面向对象的思想进行系统设计时，前人共总结出了7条原则，它们分别是：单一职责原则、开闭原则、里式替换原则、依赖注入原则、接口分离原则、迪米特原则和优先使用组合而不是继承原则

1、单一职责原则

英文缩写是 SRP，全称是 Single Responsibility Principle。

核心思想就是：系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。

就是开发人员经常说的“高内聚、低耦合”。也就是说，每一个类应该只有一个职责，对外只能提供一种功能，而引起类变化的原因应该只有一个。在设计模式中，所有的设计模式都遵循这一原则。

比如用户的属性和用户的行为被放在一个接口中声明，这就造成了业务对象和业务逻辑被放在一起，使得接口有两种职责，造成职责不明确，违背了接口的单一职责原则。

2、开闭原则

英文缩写是 OCP，全称是 Open for Extension,Close for Modification。

核心思想是：一个对象对外扩展开放，对修改关闭。

对类的改动是通过增加代码进行的，而不是改动现有代码。也就是说，开发人员一旦写出了可以运行的代码，就不应该去改变它，而是要保证它能一直运行下去，如果才能做到这一点呢？这就需要借助于抽象和多态，即把可能变化的内容抽象出来，从而使抽象的部分是相对稳定的，而具体的实现层是可以改变和扩展的。

3、里式替换原则

英文缩写是 LSP，全称是 Liskov Substitution Principle。

核心思想是：在任何父类出现的地方都可以用它的子类来替换。这个原则是为了良好的继承定义了一个规范，简单地讲，有4层含义：

子类必须完全实现父类的方法

子类可以有自己的特性

覆写或实现父类的方法时，输入参数可以被放大

覆写或实现父类的方法时，输出结果可以被缩小

4、依赖注入原则

英文缩写是 DIP，全称是 Dependence Inversion Principle。

核心思想是：要依赖于抽象，不要依赖于具体的实现。

在应用程序中，所有的类如果使用或依赖其他的类，则都应该依赖于它们的抽象类，而不是它们的具体实现类。依赖注入主要有三种实现方式：

通过构造函数传递依赖对象

通过 setter 方法传递依赖对象

通过方法参数传递依赖对象（参数必须是接口或抽象类）

5、接口分离原则

英文缩写是 ISP，全称是 Interface Segregation Principle。

核心思想是：不应该强迫客户程序依赖它们不需要使用的方法。

一个接口不需要提供太多的行为，一个接口应该只提供一个对外功能，不应该把所有的操作都封装到一个接口中。在使用接口分离原则的时候，需要有一些规范：

接口尽量小：接口尽量小，这主要是为了保证一个接口只服务于一个子模块或者业务逻辑。

接口高内聚：接口高内聚是对内高度依赖，对外尽可能隔离。即一个接口内部声明的方法相互之间都与某一个子模块相关，且是这个子模块必需的。

接口设计是有限度的：如果完全遵循接口分离原则的话，会出现一
7fe0
个问题，即接口的设计力度会越来越小，这样就造成了接口数量剧增，系统复杂度一下子增加了，而这不是真实项目所需要的。

6、迪米特原则

英文缩写 LOD ，全称是 Law of Demeter。

核心思想是：一个对象应当对其他对象尽可能少地了解。

降低各个对象之间的耦合，提高系统的可维护性。在模块之间，应该只通过接口来通信，而不理会模块的内部工作原理，它可以使各个模块的耦合度降到最低，促进软件的服用。

7、优先使用组合而不是继承原则