​超方便！掌握依赖注入5大原则，无需额外编代码！

全文共 1863 字，预计学习时长 6 分钟

图源：Unsplash

如果是第一次接触这个概念，可能会一时没有头绪，网上的各种解释可能会让你更加混乱，并觉得它没那么简单。 其实依赖注入本身是单纯、简单的。

简单来说，依赖注入是一种方式、方法或者说手段，是让被注入者和注入者之间建立关联的手段。

依赖注入的目的是松耦合，是交互对象之间的松耦合。

今天，小芯带来的文章主要描述了关于进行依赖注入（dependency injection，DI）的五大原则，具有强大的实用性。

遵循这五大基本思想，在进行DI时，你就无需额外花功夫于编写代码啦，超方便。

五大基本原则

一、保持简单的构造函数

构造函数应该保持简单。 类的构造函数不应该做任何工作——也就是说，除了检查null、创建可创建类和存储依赖项供以后使用之外，它们不应该做任何事情。

它们不应该包含任何编码逻辑。 一个类构造函数中没有检查null的if子句，那么这个类就会被分成两个类。 （有不涉及if语句检查nil-value参数的方法。 ）

复杂的构造函数表明类做的工作太多。 保持构造函数简短、简单且无逻辑。

二、不要假设接口是抽象的

接口很不错，我一直对它赞不绝口。 然而，重要的是要认识到并非每个接口都是抽象的。

例如，如果接口是公共部分类的精确表示，实际上并没有抽象任何东西，对吗? （这些接口被称为头接口，类似于c++的头文件）。 从类中提取的接口可以很容易地单独与该类紧密耦合，使得接口作为抽象类毫无用处。

最后，抽象类可能是有漏洞的——也就是说，它们可以揭示关于实现类的特定细节。 有漏洞的抽象类通常也与特定的实现类绑定在一起。

图源：Unsplash

三、不要对实现类做任何假设

当然，如果没有实现类，接口是毫无用处的。 但是，作为开发人员不应对实现类做任何假设。

只该根据接口生成的契约进行编码。 你可能已经编写了实现，但不应该在考虑实现的情况下针对接口编写代码。 换句话说，针对接口的代码就好像一个全新的、更好的接口实现。

一个设计良好的接口会告诉你需要做什么以及如何使用它。 该接口的实现对你使用该接口是无关紧要的。

四、针对抽象类而非实现类的代码

该短语出自“四人帮”之一的埃里希·伽玛（Erich Gamma）（《设计模式》一书的作者），是一个重要的想法。 如果只能教给新的开发者一件事，那就是这句格言。

抽象类是灵活的——通常是接口但不总是（见下文）。

接口(或抽象类)可以通过多种方式实现。 可以在实现完成前对接口进行编码。 如果对实现进行编码，将创建一个紧密耦合且不灵活的系统。 不要把自己限定在单一的实现中。 相反，使用抽象，编出可扩展、可重用及灵活的代码。

五、永远不要创建不该创建的东西

类别应该遵循 单一职责原则 ——即一个类只做一件事。

如此，就不应再创建事物，否则是做了两件事。 相反，应根据其所需的功能创建和提供该功能。

可创建类 vs 可注入类

那么应该创建什么呢?

我们应该关注两种不同的对象:可创建类和可注入类。

可创建类指应该继续创建的类。 是常见的运行库或实用程序类。

通常运行库中的类被认为是可创建类。 这些类应该被创建，而非注入。 它们的使用期限很短，通常不超过一种方法的范围。 可创建类在所有类中是必不可少的，可以在构造函数中创建。 一个可创建类只能传递给构造函数的另一个类。

另一方面，可注入类是我们永远不想直接创建的类。 也是不希望硬编码依赖项的类，应始终通过DI传递。

在构造函数中，它们通常被作为是依赖项。 根据以上规则，可注入类应该依赖接口注入的类，而非实例。

它通常是作为业务逻辑而编写的类。 隐藏在抽象类后，通常是接口。 还要注意，可注入类可在构造函数中请求其他的可注入类。

图源：Unsplash

适当使用DI对代码的意义重大。 做好这件事并不难，但确实需要有远见、计划和设计。

但是，在维护代码时，小小的工作将带来大大的回报。 修复松散耦合的代码是维护人员的梦想，我们要努力编写这样的代码，相信事后会收获满满。

推荐阅读专题

留言 点赞 发个朋友圈

我们一起分享AI学习与发展的干货

编译组：张淑霏、王小燕

相关链接：

https://medium.com/better-programming/five-principles-of-dependency-injection-5bd0cca9cb04

如需转载，请后台留言，遵守转载规范

推荐文章阅读

ACL2018论文集50篇解读

EMNLP2017论文集28篇论文解读

2018年AI三大顶会中国学术成果全链接

ACL2017 论文集：34篇解读干货全在这里

10篇AAAI2017经典论文回顾

长按识别二维码可添加关注

读芯君爱你