掌握依赖注入5大原则，无需额外编代码！
如果是第一次接触这个概念，可能会一时没有头绪，网上的各种解释可能会让你更加混乱，并觉得它没那么简单。 其实依赖注入本身是单纯、简单的。
简单来说，依赖注入是一种方式、方法或者说手段，是让被注入者和注入者之间建立关联的手段。
依赖注入的目的是松耦合，是交互对象之间的松耦合。
今天，小芯带来的文章主要描述了关于进行依赖注入（dependency injection，DI）的五大原则，具有强大的实用性。
遵循这五大基本思想，在进行DI时，你就无需额外花功夫于编写代码啦，超方便。
一、保持简单的构造函数
构造函数应该保持简单。 类的构造函数不应该做任何工作——也就是说，除了检查null、创建可创建类和存储依赖项供以后使用之外，它们不应该做任何事情。
它们不应该包含任何编码逻辑。 一个类构造函数中没有检查null的if子句，那么这个类就会被分成两个类。 （有不涉及if语句检查nil-value参数的方法。 ）
复杂的构造函数表明类做的工作太多。 保持构造函数简短、简单且无逻辑。
二、不要假设接口是抽象的
接口很不错，我一直对它赞不绝口。 然而，重要的是要认识到并非每个接口都是抽象的。
例如，如果接口是公共部分类的精确表示，实际上并没有抽象任何东西，对吗? （这些接口被称为头接口，类似于c++的头文件）。 从类中提取的接口可以很容易地单独与该类紧密耦合，使得接口作为抽象类毫无用处。
最后，抽象类可能是有漏洞的——也就是说，它们可以揭示关于实现类的特定细节。 有漏洞的抽象类通常也与特定的实现类绑定在一起。
三、不要对实现类做任何假设
当然，如果没有实现类，接口是毫无用处的。 但是，作为开发人员不应对实现类做任何假设。
只该根据接口生成的契约进行编码。 你可能已经编写了实现，但不应该在考虑实现的情况下针对接口编写代码。 换句话说，针对接口的代码就好像一个全新的、更好的接口实现。
一个设计良好的接口会告诉你需要做什么以及如何使用它。 该接口的实现对你使用该接口是无关紧要的。
四、针对抽象类而非实现类的代码
该短语出自“四人帮”之一的埃里希·伽玛（Erich Gamma）（《设计模式》一书的作者），是一个重要的想法。 如果只能教给新的开发者一件事，那就是这句格言。
抽象类是灵活的——通常是接口但不总是（见下文）。
接口(或抽象类)可以通过多种方式实现。 可以在实现完成前对接口进行编码。 如果对实现进行编码，将创建一个紧密耦合且不灵活的系统。 不要把自己限定在单一的实现中。 相反，使用抽象，编出可扩展、可重用及灵活的代码。
五、永远不要创建不该创建的东西
类别应该遵循 单一职责原则 ——即一个类只做一件事。
如此，就不应再创建事物，否则是做了两件事。 相反，应根据其所需的功能创建和提供该功能。
可创建类 vs 可注入类
那么应该创建什么呢?
我们应该关注两种不同的对象:可创建类和可注入类。
可创建类指应该继续创建的类。 是常见的运行库或实用程序类。
通常运行库中的类被认为是可创建类。 这些类应该被创建，而非注入。 它们的使用期限很短，通常不超过一种方法的范围。 可创建类在所有类中是必不可少的，可以在构造函数中创建。 一个可创建类只能传递给构造函数的另一个类。
另一方面，可注入类是我们永远不想直接创建的类。 也是不希望硬编码依赖项的类，应始终通过DI传递。
在构造函数中，它们通常被作为是依赖项。 根据以上规则，可注入类应该依赖接口注入的类，而非实例。
它通常是作为业务逻辑而编写的类。 隐藏在抽象类后，通常是接口。 还要注意，可注入类可在构造函数中请求其他的可注入类。
适当使用DI对代码的意义重大。 做好这件事并不难，但确实需要有远见、计划和设计。
但是，在维护代码时，小小的工作将带来大大的回报。 修复松散耦合的代码是维护人员的梦想，我们要努力编写这样的代码，相信事后会收获满满。
原文：https://mp.weixin.qq.com/s/5-Cxb8y1J5msxVk4-FA1Uw
相关链接：https://medium.com/better-programming/five-principles-of-dependency-injection-5bd0cca9cb04
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！