【译】Understanding SOLID Principles - Dependency Inversion

Understanding SOLID Principles: Dependency Inversion

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

写在前头

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

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

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

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年提出的,遵循这些原则可以帮助我们更好的构建,低耦合、高内聚的软件架构,同时能够真正的对现实中的业务逻辑进行恰到好处的封装。

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

关于原则和模式的知识能够帮助你决定在何时何地正确的使用它们。尽管这些原则仅仅是启示性的,它们是常见问题的常规解决方案。实践中,这些原则的正确性已经被证实了很多次,所以它们应当成为一种常识。

依赖倒置原则是什么

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

这两句话的意思是什么呢?

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

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

现在仔细读这两句话,我们能够得到什么暗示呢?

依赖倒置原则存在的真正意义是指,我们需要将一些对象解耦,它们的耦合关系需要达到当一个对象依赖的对象作出改变时,对象本身不需要更改任何代码。

这样的架构可以实现一种松耦合的状态的系统,因为系统中所有的组件,彼此之间都了解很少或者不需要了解系统中其余组件的具体定义和实现细节。它同时实现了一种可测试和可替换的系统架构,因为在松耦合的系统中,任何组件都可以被提供相同服务的组件所替换。

但是相反的,依赖倒置也有一些缺点,就是你需要一个用于处理依赖倒置逻辑的容器,同时,你还需要配置它。容器通常需要具备能够在系统中注入服务,这些服务需要具备正确的作用域和参数,还应当被注入正确的执行上下文中。

以提供Websocket连接服务为例子

举个例子,我们可以在这个例子中学到更多关于依赖倒置的知识,我们将使用Inversify.js作为依赖倒置的容器,通过这个依赖倒置容器,我们可以看看如何针对提供Websocket连接服务的业务场景,提供服务。

比如,我们有一个web服务器提供WebSockets连接服务,同时客户端想要连接服务器,同时接受更新的通知。当前我们有若干种解决方案来提供一个WebSocket服务,比如说Socket.ioSocks或者使用浏览器提供的关于原生的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可以提供一些更简单易用的绑定,可以通过浏览它的网站来了解。

译者注

一般说到依赖倒置原则,往往第一个想到的术语即是依赖注入,这种在各个技术栈都有应用,之后又会马上想到springng等前后端框架。

我们确实是通过使用这些框架熟知这个概念的,但是如果你仔细想想的话,是否还有其他的一些场景也使用了类似的概念呢?

比如:

  • 一些使用插件和中间件的框架,如expressredux
  • js中this的动态绑定
  • js中的回调函数

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏用户画像

13年5月 软考笔记整理

虚拟存储器为了给用户提供更大的随机存储空间而采用的一种存储技术。它将内存(主存)与外存(辅存)结合使用,好像有一个容量巨大的内存储器,工作速度接近于主存,每位成...

933
来自专栏Java学习网

书写高质量代码之状态维护

状态之始 我们第一眼接触新事物所触发的思考方式,决定了以后我们看待这样事物的角度,进而影响更深层次的理解和行为。 编程相对于人类历史的进程而言,不过是个六七岁孩...

3645
来自专栏java一日一条

书写高质量代码之状态维护

我们第一眼接触新事物所触发的思考方式,决定了以后我们看待这样事物的角度,进而影响更深层次的理解和行为。

651
来自专栏平凡文摘

成为java高级程序员需要掌握哪些

1453
来自专栏编程

使用JavaScript开发一个自修改代码

话说在25年前,我刚刚开始从事软件开发。在工作中,我遇到一个叫Dave的朋友,他曾在一家大型保险公司工作过几年,他的工作重点是开发支持一个名为“个人人寿保险”的...

2797
来自专栏Data Analysis & Viz

手把手教你完成一个数据科学小项目(2):数据提取、IP查询

本系列将全面涉及本项目从爬虫、数据提取与准备、数据异常发现与清洗、分析与可视化等细节,并将代码统一开源在GitHub:DesertsX/gulius-proje...

931
来自专栏JAVA高级架构

两年Java程序员面试经

工作两年有余,本人第一份工作是在一家外包公司,第二份工作是在一家做SAAS平台的公司,第一家公司让我入门,进入了软件开发的行业,了解了一些基础的东西;第二家公司...

2872
来自专栏java一日一条

有经验的Java开发者和架构师容易犯的10个错误(上)

首先允许我们问一个严肃的问题?为什么Java初学者能够方便的从网上找到相对应的开发建议呢?每当我去网上搜索想要的建议的时候,我总是能发现一 大堆是关于基本入门的...

762
来自专栏最高权限比特流

漫谈计算机组成原理(一)程序是怎么跑起来的

我们知道,计算机是由软件和硬件共同组成的。没有硬件,软件就没有用武之地;没有软件,硬件就只能是一堆废铁。 而软件又分为两类:

2634
来自专栏纯洁的微笑

看程序员怎么解决食堂排队问题

在学校的时候,我不爱去食堂成功,一是由于暗黑料理,更重要的一点是人太多了,队伍往往从窗口排到了门口,点菜、计算价格、付款三种业务由打饭阿姨一人完成,思维切换忙碌...

881

扫码关注云+社区