JavaScript 中的 SOLID 原则

你可能已经了解过一些设计原则或者设计模式，本文主要渐进的讲解了SOLID原则：

- 不使用SOLID是怎么编写代码的，存在什么问题？

- 应该使用SOLID中的哪个原则？

- 使用SOLID我们应该如何对代码进行修改？

相信对比和沉浸式的示例会让你更容易理解SOLID原则，以及如何应用到代码实践中。

> 这是SOLID的一篇翻译文章，作者是[serhiirubets](https://hackernoon.com/u/serhiirubets)。

这是一篇汇总，你也可以分章阅读：

[JavaScript 中的 SOLID 原则（一）：“S”代表什么](https://mp.weixin.qq.com/s/biFxh81cO2YLaIPZeTVC9A)

[JavaScript 中的 SOLID 原则（二）：“O”代表什么](https://mp.weixin.qq.com/s/2PmY9YTgvEKR_-nxosW7dA)

[JavaScript 中的 SOLID 原则（三）：“L”代表什么](https://mp.weixin.qq.com/s/D3Eq2dX0DWHwW3rFrLCYcg)

[JavaScript 中的 SOLID 原则（四）：“I”代表什么](https://mp.weixin.qq.com/s/4FTAtP4rNjfetkcWU60Lxw)

[JavaScript 中的 SOLID 原则（五）：“D”代表什么](https://mp.weixin.qq.com/s/ie7DZRUFkwQpxK4Ofi7mzQ)

在本文中，我们将讨论什么是 SOLID 原则，为什么我们应该使用他们和如何在JavaScript中使用他们。

#### 什么是SOLID

SOLID 是 Robert C. Martin 的前五个面向对象设计原则的首字母缩写词。 这些原则的目的是：让你的代码、架构更具可读性、可维护性、灵活性。

##### 单一职责原则(Single Responsibility Principle)

**S - 单一职责原则** 一个实体应该解决一项特定任务。

当我们的类(函数、组件、服务)做很多东西，那就会得到一堆关联的代码，如果改动一处可能会影响到其他地方，这些地方其实没有相关性。而且这个类很难维护，新增的代码改动可能会影响到其他地方，造成不可预知的问题。可读性也会很差，如果这个文件代码量很大，理解起来会异常痛苦。

我们先来看一端没有使用单一原则的示例：

```javascript

class Movie {

constructor(options){

this.name = options.name;

this.description = options.description;

this.rating = options.rating;

}

changeDescription (newDescription) {

this.description = newDescription;

}

changeRat ing (newRating) {

this.rating = newRating;

}

saveUserToFile() []

saveUserToDB() []

}

```

我们写了一个简单的类Movie，并提供了一个方法来修改描述、评级、保存电影到数据库或文件系统。看上去没有什么问题，但是考虑到未来可能新增的扩展：

- 我们可能会添加一些新的方法，比如：从数据库中获取一部电影的数据，在保存电影的时候进行验证，从数据库中删除电影等，我们的类将会是“God Object”反模式(“上帝模式”:一个类做了太多事情，或者把很多不相关的逻辑放到了一个类中来完成)。

- 我们可能会修改一个方法，很大概率上会影响其他地方。

- 重复的代码。我们可能还有其他的类，比如Audio或Picture，这些类可能也会使用类似的数据库、文件系统、和验证方法，我们应该怎么做呢？第一个想法可能是在每个类(Audio、Picture、Movie)中去写同样的方法，这刚好就是第二个反模式“DRY”(Don't repeat yourself.)。而且如果系统中包含很多类，每个类都有自己的方法，当做调整的时候大概率会忘记修改某个类的逻辑，这就会造成问题。

- 更难理解和维护。

那么如何重写代码逻辑来解决这些问题？我们应该先想起使用“单一职责原则”，“单一职责”实际上就是“一个实体解决一个特定的任务”。那再“Movie”类中有什么任务呢？

- 处理电影数据

- 操作数据库

- 操作文件系统

那我们就可以创建3个类：Movie、DB、FileSystem。

```javascript

class Movie {

   constructor(options) {

       this.name = options.name ;

       this.description = options.description;

       this.rating = options.rating;

  }

   changeDescription(newDescription) {

       this.description = newDescription;

  }

   changeRat ing (newRating) {

       this.rating = newRating;

  }

}

class DB {

   constructor(options) {

       this.url = options.url;

       this.loginname = options.loginname;

       this.password = options.password;

  }

   save(data) {}

   delete(id) {}

}

class FileSystem {

   constructor(options) {

       this.name = options.name;

  }

   save(data) {}

   delete(data) {}

}

```

现在我们有了3个独立的类，每个类只用来完成一个特定的任务。这样分离有以下好处：

- **DRY原则**。我们不需要再重复DB(文件)的逻辑，可以把任何实体(音乐、图片)传递给DB类，类会将他们保存到DB。

- 代码可读性更好，逻辑更简单。

- 没有了“God Object”

##### 开闭原则（Open-Closed Principle）

**O - 开闭原则**。实体(类、模块、方法、文件等)应该对扩展开放，对修改关闭。从定义上很难理解，来看几个例子：

假设：我们有几个不同的形状，圆形、方向、三角形，需要计算他们的面积总和。如何解决呢？

没什么难的，让我们为每个形状创建一个类，每个类有不同的字段：大小、高度、宽度、半径和类型字段。当计算每个形状的面积时，我们使用类型字段来区分。

```javascript

class Square{

constructor(size){

this.size = size;

this.type ='square' ;

}

}

class Circle{

constructor(radius) {

this.radius = radius;

this.type = 'circle' ;

}

}

class Rect{

constructor(width, height) {

this.width = width

this.height = height;

this.type = 'rect' ;

}

}

```

我们再创建一个函数，来计算面积。

```javascript

function getTotalAreas (shapes){

return shapes.reduce((total, shape) =>{

if (shape.type =='square') {

total += shape.size * shape.size;

}else if (shape.type = 'circle') {

total += Math.PI * shape.radius;

}else if (shape. type == ' rect') {

total += shape.width * shape.height;

}

return total;

}, 0);

}

getTotalAreas([

new Square(5),

new Circle(4),

new Rect(7,14)

]);

```

似乎看起来并没有什么问题，但是想象一下，如果我们想添加另一个形状(原型、椭圆、菱形)，我们应该怎么做？我们需要为他们中的每一个创建一个新的类，定义类型并在getTotalAreas中添加新的if/else。

**注意：** **O - 开闭原则**。让我们再重复一遍：这个原则是指：实体(类、模块、方法等)应该对扩展开放，对修改关闭。

在getTotalAreas中，每次添加新的形状都需要进行修改。这不符合*开闭原则*，我们需要做什么调整？

我们需要在每个类中创建getArea方法(类型字段已经不再需要，已被删除)。

```javascript

class Square {

constructor(size) {

this.size = size;

}

getArea() {

return this.size * this.size;

}

}

class Circle {

constructor(radius) {

this.radius = radius;

}

getArea() {

return Math.PI * (this.radius * this.radius);

}

}

class Rect {

constructor(width, height) {

this.width = width;

this.height = height;

}

getArea() {

return this.width * this.height;

}

}

function getTotalAreas (shapes) {

return shapes. reduce((total, shape) => {

return total + shape. getArea();

},0)

}

getTotalAreas([

new Square(5),

new Circle(4),

new Rect(7,14)

]);

```

现在我们已经遵循了开闭原则，当我们要添加另一个形状，比如三角形，我们会创建一个Triangle类(对扩展开放)，定义一个getArea方法，仅此而已。我们不需要修改getTotalAreas方法(对修改关闭)，只需要在调用getTotalAreas时向其数组增加一个参数。

我们再来看一个更实际的例子, 假设客户端接收一个指定格式的错误验证消息：

```javascript

const response = {

errors: {

name: ['The name field should be more than 2 letters', 'The name field should not contains numbers'] ,

email: ['The email field is required'],

phone: ['User with provided phone exist']

}

}

```

想象一下，服务端可能会使用不同的服务来验证，可能是我们自己的服务，也可能是返回不同格式错误信息的外部服务。

让我们使用尽可能用简单的示例来模拟错误信息：

```javascript

const errorFromFacebook ='Bad credentials' ;

const errorFromTwitter = ['Bad credentials'];

const errorFromGoogle = { error: 'Bad credentials' }

function requestToFacebook() {

return {

type: 'facebook',

error: errorFromFacebook

}

}

function requestToTwitter() {

return {

type: 'twitter',

error: errorFromTwitte

}

}

function requestToGoogle() {

return {

type: 'google',

error: errorFromGoogle

}

}

```

我们来把错误信息转换成客户端所需要的格式：

```javascript

function getErrors() {

const errorsList = [requestToFacebook(), requestToTwitter(), requestToGoogle()];

const errors = errorsList.reduce((res, error) => {

if (error.type == ' facebook') {

res.facebookUser = [error.error]

}

if (error.type == 'twitter') {

res.twitterUser = error.error;

}

if (error.type == 'google') {

res.googleUser = [error.error];

}

return res;

},[]);

return { errors };

}

console.log(getErrors());

```

我们就得到了客户端所期望的结果：

```javascript

{

errors: {

facebookUser:['Bad credentials'],

twitterUser:['Bad credentials'],

googleUser:['Bad credentials']

}

}

```

但是，还是同样的问题，我们没有遵循**开闭原则**，当我们需要从外部服务添加一个新的验证时，我们就需要修改getErrors方法，添加新的if/else逻辑。

怎么解决这个问题呢？一个可行的解决方案是：我们可以创建一些通用的错误验证类，并在其中定义一些通用的逻辑。我们就可以为每个错误创建一个我们自己的类(FaceBookValidationError，GoogleValidationError)。

在每个类中，我们可以指定方法，像getErrors或TransformErrors,每个validationError类都应该遵循这个规则。

```javascript

const errorFromFacebook =' Bad credentials ' ;

const errorFromTwitter = ['Bad credentials'];

const errorFromGoogle = {error: ' Bad credentials'}

class ValidationError {

constructor(error) {

this.error = error;

}

getErrors() {}

}

class FacebookValidationError extends ValidationError {

getErrors() {

return { key: ' facebookUser', text:[this.error] };

}

}

class TwitterValidationError extends ValidationError {

getErrors() {

return {

key: ' twitterUser',

text: this.erro

}

}

}

class GoogleValidationError extends ValidationError {

getErrors() {

return { key: ' googleUser', text: [this.error.error] }

}

}

```

我们来在Mock的函数中使用这个错误验证类，修改getErrors函数：

```javascript

function requestToFacebook() {

return new FacebookValidationError(errorFromFacebook)

}

function requestToTwitter() {

return new TwitterValidationError(errorFromTwitter)

}

function requestToGoogle() {

return new GoogleValidationError(errorFromGoogle)

}

function getErrors (errorsList) {

const errors = errorsList.reduce((res, item) => {

const error = item.getErrors();

res[error.key] = error.text

return res ;

}, {});

return {errors}

}

console.log(getErrors([requestToFacebook(), requestToTwitter(), requestToGoogle()]));

```

可以看到，在getErrors函数接收errorList作为参数，而不是在函数中进行硬编码。运行结果是一样的，但是我们遵循了开闭原则，当新增一个错误时：我们可以为这个错误创建一个新的验证类并且指定getErrors方法(对扩展开放)，getErrors可以帮我们把外部服务返回的信息转换成我们需要的格式。我们在通用的getErrors方法中来调用错误类的getErrors，无需进行其他修改(对修改关闭)。

#### 里氏替换原则（Liskov Substitution Principle）

**L - 里氏替换原则**。这个原则是指：如果S是T的子类型，那么程序中的T对象可以被S对象替换，不需要改变程序中任何所需属性。从定义上可能没有办法清晰的理解其含义，我们稍微换一个说法：函数中使用的指针或引用基类必须可以替换为其派生类。

让我们用更简单的方式来描述它，例如：你有一个“Car”类，并且在不同地方进行了使用。这个原则的意思是：每一个使用Car类的地方，都应该可以被Car类的子类替换。如果我们有一个继承自“Car“的“Passenger Car”, 或者有一个“SUV”类也继承自“Car“，如果我们把“Car”类替换成“SUV”类或者“Passenger Car”类，即把父类Car替换成任何一个子类后，我们的系统应该像以前一样正常工作。

举个简单的例子，我们有一个“Rectangle”(矩形)类，因为”正方形“也是“矩形”，我们可以创建一个基本的“Rectangle”类和“Square”类，“Square”继承自“Rectangle”。

```javascript

class Rectangle {

constructor(width,height) {

this.width = width

this.height = height

}

setWidth(width) {

this.width = width

}

setHeight(height) {

this.height = height

}

getArea() {

return this.width * this.height

}

}

// Square计算面积的方式有点不同，它的高度和宽度一样的,重写setWidth和setHeight方法。

class Square extends Rectangle {

setWidth(width) {

this.width = width;

this.height = width;

}

setHeight(height) {

this.width = height;

this.height = height;

}

}

```

```javascript

const rectangleFirst = new Rectangle(10, 15)

const rectangleSecond = new Rectangle(5, 10)

console.log(rectangleFirst.getArea()); // 150

console.log(rectangleSecond.getArea()); // 50

rectangleFirst.setWidth(20)

rectangleSecond.setWidth(15)

console.log(rectangleFirst.getArea()); // 300

console.log(rectangleSecond.getArea()); // 150

```

我们创建了两个实例，查看了矩形面积，更改宽高并再次检查了面积，我们看到一切正常，代码按预期工作，但是，让我们再看一下**里氏替换原则**：如果我们更改任何子类的基类，我们的系统应该像以前一样工作。

```javascript

const rectangleFirst = new Square(10, 15)

const rectangleSecond = new Square(5, 10)

console.log(rectangleFirst.getArea()); // 150

console.log(rectangleSecond.getArea()); // 50

rectangleFirst.setWidth(20)

rectangleSecond.setWidth(15)

console.log(rectangleFirst.getArea()); // 400

console.log(rectangleSecond.getArea()); // 225

```

我们把`new Rectangle()` 替换为`new Square()`后发现，在`setWidth`之后, `getArea`返回了和替换之前不同的值，很明显我们没有遵循里氏替换原则。

那么我们应该怎么解决呢？解决方案是使用继承，但不是从”Rectangle“类，而是准备一个更“正确”的类。比如，我们创建一个“Sharp”类，它只负责计算面积：

```javascript

class Shape {

getArea() {

return this.width * this.height;

}

}

class Rectangle {

constructor(width,height) {

super();

this.width = width

this.height = height

}

setWidth(width) {

this.width = width

}

setHeight(height) {

this.height = height

}

}

class Square extends Shape {

setWidth(width) {

this.width = width;

this.height = width;

}

setHeight(height) {

this.width = height;

this.height = height;

}

}

```

我们创建了一个更通用的基类`Shape`，在使用`new Shape()`的地方我们都可以把`Shape`修改为任何它的子类，而不会破坏原有逻辑。

在我们的示例中，Rectangle和Square是不同的对象，它们包含了一些相似的逻辑，但也有不同的逻辑，所以把他们分开而不是用作“父子”类会更正确。

我们再来看一个对理解这个原则有帮助的例子：

我们要创建一个`Bird`类，我们正在考虑应该添加什么方法，从第一个角度来看，我们可以考虑添加`fly`方法，因为所有的鸟都会飞。

```javascript

class Bird{

fly(){}

}

function allFly(birds) {

birds.forEach(bird => bird.fly())

}

allFly([new Bird(), new Bird(), new Bird()])

```

之后，我们意识到存在不同的鸟类：鸭子、鹦鹉、天鹅。

```javascript

class Duck extends Bird {

quack(){}

}

class Parrot extends Bird {

repeat(){}

}

class Swan extends Bird{

beBeautiful(){}

}

```

现在，里氏替换原则说，如果我们把基类更改为子类，系统应该像以前一样工作：

```javascript

class Duck extends Bird {

quack(){}

}

class Parrot extends Bird {

repeat(){}

}

class Swan extends Bird{

beBeautiful(){}

}

function allFly(birds){

birds.forEach(bird=> bird.fly())

}

allFly([new Duck(), new Parrot(), new Swan()])

```

我们在调用`allFly`函数时，改变了参数，我们调用了`new Duck()`,`new Parrot()`,`new Swan()`, 而不是调用`new Bird()`。一切正常，我们正确的遵循了里氏替换原则。

现在我们想再添加一只企鹅，但是企鹅并不会飞，如果想调用`fly`方法，我们就抛出一个错误。

```javascript

class Penguin extends Bird {

fly(){

throw new Error('Sorry, but I cannot fly')

}

swim(){}

}

allFly([new Duck(), new Parrot(), new Swan(), new Penguin()])

```

但是我们遇到一个问题：fly方法并不期望出现内部错误，allFly方法也只是为会飞的鸟创建的，企鹅不会飞，所以我们违背了里氏替换原则。

怎么解决这个问题？与其创建一个基本的`Bird`类，不如创建一个`FlyingBird`类，所有会飞的鸟都只继承自`FlyingBird`类，allFly方法也只接受`Flying Bird`。

```javascript

class Bird{

}

class FlyingBird{

fly(){}

}

class Duck extends FlyingBird {

quack(){}

}

class Parrot extends FlyingBird {

repeat(){}

}

class Swan extends FlyingBird{

beBeautiful(){}

}

class Penguin extends Bird {

swim(){}

}

```

`Penguin`继承自Bird类，而不是FlyingBird类，我们也不需要调用会引发错误的fly方法。在任何调用FlyingBird的地方，可以直接换成更具体的鸟类，比如Duck、Parrot、Swan，代码也会正常工作。

希望你可以通过本文能够更好的理解*里氏替换原则*，了解在JavaScript是如何工作的和如何在项目中使用。

#### 接口隔离原则（Interface Segregation Principle）

**I - 接口隔离原则**。这个原则是指：客户端不应该依赖他们不使用的接口(接口应该是精简的，拥有尽可能少的行为)。

这是什么意思? 这个原则是关于接口的，但是在JavaScript中没有接口，不过有类似的东西，那就是类。虽然两者不一样，但是这个原则可以应用到JS类上。

对于JS类来说，这个原则是指当我们创建一个基础类，需要在其中定义所有子类都会用到的方法，并且避免只有部分子类会用到的方法。

举个简单的例子，当我们创建一个`Transport`的基础类并添加以下方法：move、stop、fly和sail。示例中的方法只添加了`console.log`，实际应用中对应的应该是真正的业务逻辑。

```javascript

class Transport {

move() {

console.log('move');

}

stop() {

console.log('stop');

}

fly() {

console.log('fly');

}

sail() {

console.log('sail');

}

}

```

我们再创建三个子类：Plane, Car 和 Ship。

```javascript

class Plane extends Transport {

sail() {

return null;

}

}

class Car extends Transport {

fly() {

return null ;

}

sail() {

return null;

}

}

class Ship extends Transport {

fly() {

return null ;

}

}

```

你可能注意到了，每个子类中重写了继承的方法，并返回了`null`。为什么这么做呢，拿Plane举例，飞机可以fly和move，但是不能sail(船类航行)。

我们的基类包含了sail逻辑，但是飞机不能sail。我们应该做一些事情，因为有人可能会调用plane实例上的sail方法，我们可以抛出错误或者像现在一样重写sail方法。其他两个类也是使用同样的处理方式，Car重写了fly和sail，ship重写了fly。

所以问题在于：我们创建的基类包含的方法，有的子类可以使用，但其他的子类不能。这就是**接口隔离原则**所指的：我们不应该在基类中创建子类不会使用到的逻辑。

当然，这个和多态没有关系，如果我们创建了一个通用的方法，但是每个子类都会重写这个方法逻辑，是可以的。

举个例子：我们有一个Animal基类，包含一个breathe方法，它的子类也可以breathe但是使用了不同的方式，我们可以使用多态：

```javascript

class Animal {

breath() {

console.log('common breath')

}

}

class Human extends Animal {

breath() {

console.log('lung breath')

}

}

class Fish extends Animal {

breath() {

console.log('gills breath')

}

}

```

再重温一下**接口隔离原则**：正确的在基类中创建方法，这些方法应该被继承的子类所使用。

那么我们怎么解决Transport类中的问题呢？我们可以创建更具体的子类，子类中包含只有自身会使用到的方法：

```javascript

class Transport {

move() {

console.log('move')

}

stop() {

console.log('stop')

}

}

class FlyingTransport extends Transport {

fly() {

console.log('fly')

}

}

class SailingTransport extends Transport {

sail() {

console.log('sail')

}

}

class Car extends Transport {}

class Plane extends FlyingTransport {}

class Ship extends SailingTransport {}

```

现在我们的Transport基类包含了move和stop两个方法，这两个方法可以用在所有的子类。我们还创建了两个具体的子类，plane可以继承FlyingTransport，轮船可以继承SailingTransport。

这就是“SOLID”原则中“I”的含义：这个原则主要的目的是让代码拥有良好的层次结构，尽量不要在基类中创建子类不需要的方法。

#### 依赖倒置原则

**D - 依赖倒置原则** 这个原则是指：高级模块不应该依赖低级模块；两者都应该依赖于抽象，抽象应该不依赖于细节，细节应该取决于抽象。

举个例子，假设我们想处理电影数据，我们创建了一个简单的Movie类：

```javascript

class Movie {

 constructor(title,description) {}

}

```

我们还需要保存视频信息到localStorage，为了遵循**单一职责原则**，我们单独创建一个类：

```javascript

class MovieStorage {

 setItem(data) {}

 getItemById(id) {}

 getAll() {}

}

```

一切都很好，而且我们的逻辑会在其他地方使用。

```javascript

const movieStorage = new MovieStorage()

const ironMan = new MovieStorage('Iron man', 'Movie about Iron man')

const spiderMan = new MovieStorage('Spider man', 'Movie about Spider man')

movieStorage.setItem(ironMan)

movieStorage.setItem(spiderMan)

// here could be different other logic

movieStorage.getItemById(1);

```

如果我们想把数据修改为存储到本地文件系统，没问题，再创建一个类：

```javascript

class MovieFileStorage {

 save(data){}

 editFile(data){}

 readMovieById(id){}

 readAllMovies(){}

}

```

现在我们需要把之前使用localStorage的地方，替换成fileStorage


看起来没有什么问题，我们只是删除并替换了4行代码，但就像我们之前讨论的，如果你在很多文件中多次使用了local Storage，很难找到所有使用的地方并正确的修改它们。而且如果你已经为此写了测试，所有测试也需要进行修改。

修改后的代码可以正常工作，但是随着时间的推移，对本地文件系统占用越来越大，我们打算切换到数据库进行存储，MongoDB或SQL，我们应该怎么做？遵循“单一职责原则”，我们创建了一个DB存储类：

```javascript

class MovieDBStorage{

 insert(data){}

 update(data){}

 selectAll(){}

 selectById(id){}

}

```

现在我们遇到了同样的问题，我们需要查找所有的文件，把文件系统的逻辑修改为数据库操作，需要查找到所有相关文件中的调用并修改方法名，签名，为此编写的测试也需要进行调整。


使用的地方越多，修改起来越困难，这也是导致代码出现bug的原因之一。

希望你可以理解这个问题，我们来看看怎么才能避免它，还记得依赖倒置原则吗：**高级模块不应该依赖低级模块；两者都应该依赖于抽象，抽象不应该依赖细节，细节应该取决于抽象。**

我们从抽象开始重构吧：我们创建一个MoveStorage类，这个类将会是我们的“抽象”。抽象不应该依赖细节，我们应该怎么实现它呢？很简单，我们为MoveStorage类创建方法，这些方法用来代替MoveDBStorage,MovieFileStorage。

```javascript

class MovieStorage {

 save(data) {}

 edit(data) {}

 getById(id) {}

 getAll() {}

}

```

这个类就像一个接口，我们所有的代码都会使用这些方法，它们的名称不会被改变，也就是说我们的高级模块(我们使用“抽象”的地方)将不依赖于我们的内部逻辑。

接下来，我们为每个存储方式创建特定的类，而且每个类使用的方法名、参数都和我们的“抽象”类保持一致：

```javascript

class MovieFileStorage {

 save(data) {}

 edit(data) {}

 getById(id) {}

 getAll() {}

}

class MovieDBStorage {

 save(data) {}

 edit(data) {}

 getById(id) {}

 getAll() {}

}

```

最后我们来调整我们的“抽象”：

```javascript

class MovieStorage {

constructor (storage) {

this.storage = storage;

}

save(data) {

this.storage.save(data)

}

edit(data) {

this.storage.edit(data)

}

getById(id) {

this.storage.getById(id)

}

getAll() {

this.storage.getAll()

}

}

```

现在我们的“抽象”已经不依赖细节了，MovieStorage接收任何存储的实例，并且实例遵循我们的接口：

```javascript

const movieStorage = new MovieStorage(new MovieFileStorage())

movieStorage.save(ironMan)

movieStorage.save(spiderMan)

moveStorage.getById(1)

```

如果我们想把文件存储修改为缓存存储、本地/会话存储、MongoDB、SQL等，我们只需要准备对应的存储类(用于mongo、redis、sql)，它应该实现和我们的“抽象”同名的方法，并把新的类实例传递到构造器中：

```javascript

const movieStorage = new MovieStorage(new MovieDBStorage())

movieStorage.save(ironMan)

movieStorage.save(spiderMan)

movieStorage.getById(1)

```

我们只是改变了传递的参数：MovieStorage接收的实例从`new MovieFileStorage()`修改成了`new MovieDBStorage()`。我们不需要查找并修改所有的文件，也不需要修改已有的测试。我们所有的文件都使用了相同的抽象，而且我们的抽象不依赖于逻辑，抽象即逻辑。

这就是JS中“SOLID”的收尾，希望你可以在时间中至少使用到他们中的一个。你可以全部使用，也可以只选择一个，比如：*单一职责原则*，查看你的代码是否都遵循了这个原则，如果没有，那就重构你的代码吧。

你也可以使用“依赖倒置原则”，并检查你的代码是否符合这个原则，幸运的是，像“Angular”或“NestJS”这些框架遵循了这个原则，你可以在使用他们的项目中看到具体的实践。

我们来做个回顾吧：

1、单一职责原则（SRP）：一个类应该有且只有一个职责，解决一项特定任务。

2、开放封闭原则（OCP）：一个类应该对扩展开放，对修改关闭。一个类在应用的其他地方已经开始使用，就不应该再修改它。

3、里氏替换原则（LSP）：派生的子类应该是可替换基类的，也就是说任何基类可以出现的地方，都可以被子类替换。值得注意的是，当通过继承实现多态行为时，如果派生类没有遵守LSP，可能会让系统引发异常。

4、接口隔离原则（ISP）：基类不应该包含他们子类不使用的方法，也就是说一个接口应该拥有尽可能少的行为。应该把那些大而全的接口拆分成一些小的、具体的接口，这样客户端就只需关心他们要用到的接口。

5、依赖倒置原则（DIP）：高级模块不应该依赖低级模块，相反，他们应该依赖抽象类或者接口。也就是不应该在高级模块中使用具体的低级模块，应该遵从依赖于抽象(接口)而不是一个实例(类)。