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

来源：今日头条        链接：https://www.toutiao.com/i6774948086293725699/

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

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

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

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

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

五大基本原则

一、保持简单的构造函数

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

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

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

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

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

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

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

 图源：Unsplash

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

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

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

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

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

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

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

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

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

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

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

可创建类 vs 可注入类

那么应该创建什么呢?

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

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

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

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

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

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

 图源：Unsplash

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

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

一THE END一

免责声明：本文来自互联网新闻客户端自媒体，不代表本网的观点和立场。

合作及投稿邮箱：E-mail:editor@tusaishared.com