读懂 SOLID 的「依赖倒置」原则

时间 2019-11-07

标签读懂 solid 依赖倒置原则栏目设计模式繁體版

原文原文链接

这是理解 SOLID原则中，关于 依赖倒置原则如何帮助咱们编写低耦合和可测试代码的第一篇文章。

写在前头

当咱们在读书，或者在和一些别的开发者聊天的时候，可能会谈及或者听到术语SOILD。在这些讨论中，一些人会说起它的重要性，以及一个理想中的系统，应当包含它所包含的5条原则的特性。程序员

咱们在每次的工做中，你可能没有那么多时间思考关于架构这个比较大的概念，或者在有限的时间内或督促下，你也没有办法实践一些好的设计理念。web

可是，这些原则存在的意义不是让咱们“跳过”它们。软件工程师应当将这些原则应用到他们的开发工做中。因此，在你每一次敲代码的时候，如何可以正确的将这些原则付诸于行，才是真正的问题所在。若是能够那样的话，你的代码会变得更优雅。spring

SOLID原则是由5个基本的原则构成的。这些概念会帮助创造更好（或者说更健壮）的软件架构。这些原则包含（SOLID是这5个原则的开头字母组成的缩略词）：数据库

S stands for SRP (Single responsibility principle)：单一职能原则
O stands for OCP (Open closed principle)：开闭原则
L stands for LSP (Liskov substitution principle)：里氏替换原则
I stand for ISP ( Interface segregation principle)：接口隔离原则
D stands for DIP ( Dependency inversion principle)：依赖倒置原则

起初这些原则是Robert C. Martin在1990年提出的，遵循这些原则能够帮助咱们更好的构建，低耦合、高内聚的软件架构，同时可以真正的对现实中的业务逻辑进行恰到好处的封装。express

不过这些原则并不会使一个差劲的程序员转变为一个优秀的程序员。这些法则取决于你如何应用它们，若是你是很随意的应用它们，那等同于你并无使用它们同样。redux

关于原则和模式的知识可以帮助你决定在什么时候何地正确的使用它们。尽管这些原则仅仅是启示性的，它们是常见问题的常规解决方案。实践中，这些原则的正确性已经被证明了不少次，因此它们应当成为一种常识。segmentfault

依赖倒置原则是什么

高级模块不该当依赖于低级模块。它们都应当依赖于抽象。
抽象不该当依赖于实现，实现应当依赖于抽象。

这两句话的意思是什么呢？后端

一方面，你会抽象一些东西。在软件工程和计算机科学中，抽象是一种关于规划计算机系统中的复杂性的技术。它的工做原理通常是在一我的与系统交互的复杂环境中，隐藏当前级别下的更复杂的实现细节，同时它的范围很广，经常会覆盖多个子系统。这样，当咱们在与一个以高级层面做为抽象的系统协做时，咱们仅仅须要在乎，咱们能作什么，而不是咱们如何作。浏览器

另外，你会针对你的抽象，有一写低级别的模块或者具体实现逻辑。这些东西与抽象是相反的。它们是被用于解决某些特定问题所编写的代码。它们的做用域仅仅在某个单元和子系统中。好比，创建一个与MySQL数据库的链接就是一个低级别的实现逻辑，由于它与某个特定的技术领域所绑定。服务器

如今仔细读这两句话，咱们可以获得什么暗示呢？

依赖倒置原则存在的真正意义是指，咱们须要将一些对象解耦，它们的耦合关系须要达到当一个对象依赖的对象做出改变时，对象自己不须要更改任何代码。

这样的架构能够实现一种松耦合的状态的系统，由于系统中全部的组件，彼此之间都了解不多或者不须要了解系统中其他组件的具体定义和实现细节。它同时实现了一种可测试和可替换的系统架构，由于在松耦合的系统中，任何组件均可以被提供相同服务的组件所替换。

可是相反的，依赖倒置也有一些缺点，就是你须要一个用于处理依赖倒置逻辑的容器，同时，你还须要配置它。容器一般须要具有可以在系统中注入服务，这些服务须要具有正确的做用域和参数，还应当被注入正确的执行上下文中。

以提供Websocket链接服务为例子

举个例子，咱们能够在这个例子中学到更多关于依赖倒置的知识，咱们将使用Inversify.js做为依赖倒置的容器，经过这个依赖倒置容器，咱们能够看看如何针对提供Websocket链接服务的业务场景，提供服务。

好比，咱们有一个web服务器提供WebSockets链接服务，同时客户端想要链接服务器，同时接受更新的通知。当前咱们有若干种解决方案来提供一个WebSocket服务，好比说Socket.io、Socks或者使用浏览器提供的关于原生的WebSocket接口。每一套解决方案，都提供不一样的接口和方法供咱们调用，那么问题来了，咱们是否能够在一个接口中，将全部的解决方案都抽象成一个提供WebSocket链接服务的提供者？这样，咱们就能够根据咱们的实际需求，使用不一样的WebSocket服务提供者。

首先，咱们来定义咱们的接口：

export interface WebSocketConfiguration {
  uri: string;
  options?: Object;
}
export interface SocketFactory {
  createSocket(configuration: WebSocketConfiguration): any;
}

注意在接口中，咱们没有提供任何的实现细节，所以它既是咱们所拥有的抽象。

接下来，若是咱们想要一个提供Socket.io服务工厂：

import {Manager} from 'socket.io-client';

class SocketIOFactory implements SocketFactory {
  createSocket(configuration: WebSocketConfiguration): any {
    return new Manager(configuration.uri, configuration.opts);
  }
}

这里已经包含了一些具体的实现细节，所以它再也不是抽象，由于它声明了一个从Socket.io库中导入的Manager对象，它是咱们的具体实现细节。

咱们能够经过实现SocketFactory接口，来增长若干工厂类，只要咱们实现这个接口便可。

咱们在提供一个关于客户端链接实例的抽象：

export interface SocketClient {
  connect(configuration: WebSocketConfiguration): Promise<any>;
  close(): Promise<any>;
  emit(event: string, ...args: any[]): Promise<any>;
  on(event: string, fn: Function): Promise<any>;
}

而后再提供一些实现细节：

class WebSocketClient implements SocketClient {
  private socketFactory: SocketFactory;
  private socket: any;
  public constructor(webSocketFactory: SocketFactory) {
    this.socketFactory = webSocketFactory;
  }
  public connect(config: WebSocketConfiguration): Promise<any> {
    if (!this.socket) {
      this.socket = this.socketFactory.createSocket(config);
    }
    return new Promise<any>((resolve, reject) => {
      this.socket.on('connect', () => resolve());
      this.socket.on('connect_error', (error: Error) => reject(error));
    });
  }
  public emit(event: string, ...args: any[]): Promise<any> {
    return new Promise<string | Object>((resolve, reject) => {
      if (!this.socket) {
        return reject('No socket connection.');
      }
      return this.socket.emit(event, args, (response: any) => {
        if (response.error) {
          return reject(response.error);
        }
        return resolve();
      });
    });
  }
  public on(event: string, fn: Function): Promise<any> {
    return new Promise<any>((resolve, reject) => {
      if (!this.socket) {
        return reject('No socket connection.');
      }
      this.socket.on(event, fn);
      resolve();
    });
  }
  public close(): Promise<any> {
    return new Promise<any>((resolve) => {
      this.socket.close(() => {
        this.socket = null;
        resolve();
      });
    });
  }
}

值得注意的是，这里咱们在构造函数中，传入了一个类型是SocketFactory的参数，这是为了知足关于依赖倒置原则的第一条规则。对于第二条规则，咱们须要一种方式来提供这个不须要了解内部实现细节的、可替换的、易于配置的参数。

这也是为何咱们要使用Inversify这个库的缘由，咱们来加入一些额外的代码和注解（装饰器）：

import {injectable} from 'inversify';
const webSocketFactoryType: symbol = Symbol('WebSocketFactory');
const webSocketClientType: symbol = Symbol('WebSocketClient');
let TYPES: any = {
    WebSocketFactory: webSocketFactoryType,
    WebSocketClient: webSocketClientType
};

@injectable()
class SocketIOFactory implements SocketFactory {...}
...
@injectable()
class WebSocketClient implements SocketClient {
public constructor(@inject(TYPES.WebSocketFactory) webSocketFactory: SocketFactory) {
  this.socketFactory = webSocketFactory;
}

这些注释（装饰器）仅仅会在代码运行时，在如何提供这些组件实例时，提供一些元数据，接下来咱们仅仅须要建立一个依赖倒置容器，并将全部的对象按正确的类型绑定起来，以下：

import {Container} from 'inversify';
import 'reflect-metadata';
import {TYPES, SocketClient, SocketFactory, SocketIOFactory, WebSocketClient} from '@web/app';
const provider = new Container({defaultScope: 'Singleton'});
// Bindings
provider.bind<SocketClient>(TYPES.WebSocketClient).to(WebSocketClient);
provider.bind<SocketFactory>(TYPES.WebSocketFactory).to(SocketIOFactory);
export default provider;

让咱们来看看咱们如何使用咱们提供链接服务的客户端实例：

var socketClient = provider.get<SocketClient>(TYPES.WebSocketClient);

固然，使用Inversify能够提供一些更简单易用的绑定，能够经过浏览它的网站来了解。

译者注

通常说到依赖倒置原则，每每第一个想到的术语便是依赖注入，这种在各个技术栈都有应用，以后又会立刻想到spring、ng等先后端框架。

咱们确实是经过使用这些框架熟知这个概念的，可是若是你仔细想一想的话，是否还有其余的一些场景也使用了相似的概念呢？

好比：

一些使用插件和中间件的框架，如express、redux
js中this的动态绑定
js中的回调函数

也许有的人会不一样意个人观点，会说依赖注入通常都是面向类和接口来说的，这确实有必定的道理，可是我认为没有必要局限在一种固定的模式中去理解依赖倒置，毕竟它是一种思想，一种模式，在js中，全部的东西都是动态的，函数是一等公民，是对象，那么把这些与依赖倒置原则联系起来，彻底也讲的通。咱们真正关心的是核心问题是如何解耦，把更多的注意力投入的真正的业务逻辑中去。

欢迎关注公众号全栈101，只谈技术，不谈人生