分享每一天-编程中的SOLID原则

编程中的SOLID原则

工具推荐 2018 0 创建时间：2020-09-03 15:47:03

编程原则

#### SOLID原则

![](http://www.seedblog.cn/uploads/article/2020-09-03/8QbSjKDu9nMMBR9ZrRUFuRD6mu60BxvNTJluw87W.png)

SOLID是指我们编程时应该遵守的五个原则：

1. 单一职责原则（The Single Responsibility Principle，简称SRP）

2. 开放——封闭原则（The Open-Close Principle，简称OCP）

3. Liskov替换原则（The Liskov Substitution Priciple，简称LSP）

4. 依赖倒置原则（The Dependency Inversion Principle，简称DIP）

5. 接口隔离原则（The Interface Segregation Principle，简称ISP）

**每个原则取一个字母（SRP，OCP，LSP，ISP，DIP），合称SOLID原则。**

#### 单一职责原则（The Single Responsibility Principle，简称SRP）

##### 定义

就一个类而言，应该只有一个引起它变化的原因。

一个类如果有多个职责，但是你只需要其中的一个职责，你也不得不将其它职责包括进来，还有其它职责所依赖的所有组件。

##### 什么是职责

在SRP中，我们把职责定义为“变化的原因”（a reason for change）。如果能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

比如Employee这个类如果同时包含了业务规则和对于持久化的控制，多数情况下，我们可以断定它们不应该放在一起：业务规则会频繁地变化，但是持久化的方式却不会如此频繁地变化，并且变化的原因也是完全不同的。

##### 结论

SRP是所有原则中最简单的，也是最难运用的。软件设计很多时候要做的，就是发现职责，并把它分离出来。事实上，我们将要论述的其它原则都会以这样或者那样的方式回到这个问题上。

####开放——封闭原则（The Open-Close Principle，简称OCP）

##### 定义

软件实体（类、模块、函数等）应该是可以扩展，但是不可修改的。

OCP的定义，换个说法：

- 对扩展开放（Open for extension）
- 对修改封闭（Close for modification）

如果程序中的一处改动就会产生连锁反应，导致一系列相关模块的改动，OCP建议我们应该对程序进行重构。重构之后再进行同样的修改，就只需要添加新的功能模块，不需要对原有的代码进行修改。

如何在能在不改变模块原代码的情况下去更改它的行为或者为其添加功能呢？

##### 关键是抽象

抽象一般有两种方式： 1. 接口 2. 继承

###### 接口

用接口对需要的对象进行抽象，也就是所谓的“面向接口编程”。

###### 继承

继承一个抽象类（和接口类似）或者重写一个父类中的（虚）方法，也是OCP的惯用伎俩。典型的例子，就是那个图形的绘制的例子。
```php

class Shape {
    func draw() {}
};

class Square: Shape {
    override func draw() {
        // draw square
    }
};

class Circle: Shape {
    override func draw() {
        // draw circle
    }
};

void drawAllShapes([Shape] list) {
    for (Shape shape in list) {
        shape.draw()
    }
}

```
如果想扩展drawAllShapes方法，使其可以绘制一种新的形状，只需要重新创建一个Shape类的子类，drawAllShapes函数不需要改变，即可实现功能的扩展。这就是OCP。

##### 什么时候进行抽象

即使是上面的形状绘制的例子，也不是完全的“对扩展开放，对修改关闭。”比如，我要求所有的圆必须在正方形之前绘制，就没法在不修改drawAllShapes的情况下进行这个功能扩展。

我们无法准确预测未来的功能扩展需求，所以，理论上来说，我们也无法实现完全的“对扩展开放，对修改关闭。”

而且更重要的，遵循OCP进行抽象的代价也是昂贵的。创建正确的抽象需要花费开发时间和精力。同时，这些抽象也增加了软件的设计复杂度。开发人员有能力处理的抽象的数量也是有限的。

所以，不要试图在刚开始就实现OCP，可以试着遵循下面的准则：

只受一次愚弄
也就是说，在刚开始编写代码的时候，假设变化不会发生。当变化发生时，我们就创建抽象进行隔离，防止以后发生同类变化。

##### 结论

在很多方面，OCP都是面向对象设计的核心所在。遵循这个原则，可以带来面向对象技术所声称的巨大好处（也就是，灵活性、可重用性以及可维护性）。但是，对程序的每个部分都肆意地进行抽象也不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

#### Liskov替换原则（The Liskov Substitution Priciple，简称LSP）

##### 定义
子类型必须能够替换掉它们的基类型。

假设一个函数f，它的参数是某个基类型B。如果将基类型B的子类D传给f，会导致f出现错误的行为，那么D就违反了LSP原则。

此时，f的编写者想在f内对D进行检测，以便在把D传给f时，可以使f具有正确的行为。这个行为又违反了OCP原则，因为此时f对于基类型B的所有子类都不在封闭。

#### 依赖倒置原则（The Dependency Inversion Principle，简称DIP）

##### 定义

高层模块不应该依赖于低级模块。二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
这里的“抽象”是指接口或者抽象类。

为什么用”倒置“：这是相对于传统的软件开发，比如结构化分析和设计。在这些设计中，倾向于创建一些高层模块依赖于低层模块的模块，策略（Policy）依赖于细节的软件结构。而DIP要求大家都依赖于抽象，而且这个抽象绝对不会放在低层模块中，而是放在高层模块中（或者独立出来一个模块），所以，不再是高层模块依赖低层模块，而是低层模块依赖高层模块（中的抽象）。

#### 接口隔离原则（The Interface Segregation Principle，简称ISP）

##### 定义

不应该强迫客户依赖于它们不用的方法。

这个原则是用来处理“胖”接口所具有的缺点。如果类的接口不是内聚（cohesive）的，就表示该类具有“胖”的接口。换句话说，类的“胖”接口可以分解成多组方法，每一组方法都服务于不同的客户程序。

如果客户程序依赖于一个具有“胖”接口的类，就相当于强迫客户程序依赖它们不使用的方法，那么这些客户程序就面临着由于这些未使用的方法的改变所带来的变更。这无意中导致了所有客户程序之间的耦合。

参考文档:https://www.dazhuanlan.com/2020/02/24/5e5335fe8562c/
参考书籍: <<架构整洁之道>> http://gdut_yy.gitee.io/doc-cleanarch/

编程中的SOLID原则

商品推荐

广告推荐

推荐文章