如果你是第一次接触这个概念，可能一时半会儿毫无头绪。网上各种解释可能让你一头雾水，觉得没那么简单。事实上，依赖注入本身是纯粹而简单的。简单的说，依赖注入就是一种途径、方法或者手段，是一种在被注入者和注入者之间建立关系的手段。依赖注入的目的是松耦合，也就是交互对象之间的松耦合。今天小新带来的这篇文章主要讲述了依赖注入（DI）的5个原则，具有很强的实用性。遵循这五个基本思路，你在做DI的时候就不需要再花额外的力气去写代码了，超级方便。五个基本原则1.保持简单的构造函数构造函数应该保持简单。类构造函数不应该做任何工作——也就是说，除了检查null、创建可创建对象和存储依赖项以供以后使用之外，它们不应该做任何其他事情。它们不应包含任何编码逻辑。没有检查null的if子句的类构造函数将分为两个类。（有一些方法可以检查不涉及if语句的nil值参数。）复杂的构造函数表明该类做了太多工作。保持构造函数简短、简单且无逻辑。其次，不要假设接口是抽象的。界面很好，一直赞不绝口。然而，重要的是要认识到并非每个接口都是抽象的。例如，如果接口是公共部分类的精确表示，它实际上并没有抽象任何东西，对吗？（这些接口称为头接口，类似于C++的头文件）。从类中提取的接口可以很容易地单独与该类紧密耦合，从而使接口作为抽象类变得无用。最后，抽象类可能容易受到攻击——也就是说，它们可以揭示有关实现类的具体细节。易受攻击的抽象类通常也绑定到特定的实现类。3.不要对实现类做任何假设当然，如果没有实现类，接口也是无用的。但是，作为开发人员，您不应该对实现类做出任何假设。只有接口生成的合同才应该被编码。您可能已经编写了实现，但您不应该在考虑实现的情况下针对接口编写代码。换句话说，针对接口的代码就像一个新的、更好的接口实现。一个设计良好的界面会告诉你需要做什么以及如何使用它。接口的实现与您对接口的使用无关。4.代码写抽象类而不是实现类这句话出自“四人帮”之一的埃里希·伽玛（ErichGamma）（《设计模式》一书的作者），是一个重要的思想。如果只有一件事可以教给新开发人员，那就是这句格言。抽象类是灵活的——通常是接口，但不总是（见下文）。接口（或抽象类）可以通过多种方式实现。可以在实现完成之前对接口进行编码。如果您对实现进行编码，则会创建一个紧密耦合且不灵活的系统。不要将自己局限于单一的实现。相反，使用抽象来编写可扩展、可重用和灵活的代码。5、不该造的东西，不要造。类别应该遵循单一职责原则——即一个类只做一件事。因此，不应再创建事物，否则将完成两件事。相反，应该根据它需要的功能来创建和提供功能。CreatablevsInjectable那么应该创建什么？我们应该关注两种不同的对象：Creatable和Injectable。可创建类是应该继续创建的类。是一个公共运行时或实用程序类。通常运行时库中的类被认为是可创建的类。这些类应该被创建，而不是被注入。它们是短暂的，通常不超过一种方法的范围。可创建类在所有类中都是必不可少的，可以在构造函数中创建。可创建的类只能在构造函数中传递给另一个类。另一方面，可注入类是我们永远不想直接创建的类。此外，您不希望硬编码依赖项的类应始终通过DI传递。在构造函数中，它们通常被视为依赖项。根据以上规则，可注入类应该依赖于接口注入的类，而不是实例。它通常是一个编写为业务逻辑的类。隐藏在一个抽象类后面，通常是一个接口。另请注意，可注入类可以在其构造函数中请求其他可注入类。正确使用DI对您的代码意义重大。做好并不难，但确实需要远见、规划和设计。但是在维护您的代码时，小努力会带来大回报。修复松散耦合的代码是维护者的梦想，我们必须努力写出这样的代码，相信之后会有收获。
