依赖注入的批评和弊端

#1 楼

首先，我想将设计方法与框架的概念区分开。在最简单，最基本的级别上进行依赖项注入很简单：


父对象提供了子对象所需的所有依赖项。


它。请注意，其中的任何内容都不需要接口，框架，任何注入样式等。为了公平起见，我20年前首次了解了这种模式。这不是什么新鲜事。

由于有两个以上的人对“父母和子女”一词感到困惑，因此在依赖注入的情况下：


父母是实例化并配置它使用的子对象的对象
子对象是旨在被动实例化的组件。即它旨在使用父级提供的任何依赖关系，并且不会实例化其自身的依赖关系。

依赖关系注入是对象组合的一种模式。

为什么要使用接口？

接口是合同。它们的存在是为了限制两个对象之间的紧密耦合。并非每个依赖项都需要一个接口，但是它们可以帮助编写模块化代码。

当您添加单元测试的概念时，对于任何给定的接口，您可能都有两种概念上的实现：您想要的真实对象在应用程序中使用，以及用于测试依赖于该对象的代码的模拟对象或存根对象。对于接口而言，仅凭此一个理由就足够了。

为什么要使用框架？

本质上初始化并提供对子对象的依赖关系可能会令人望而生畏。框架具有以下优点：


自动装配组件依赖项
使用某种设置配置组件
自动化样板代码，因此您不必看到它写在多个位置。

它们还具有以下缺点：


父对象是一个“容器”，代码中没有任何内容
如果您不能在测试代码中直接提供依赖项，它会使测试变得更加复杂
它可以解决所有问题，从而降低初始化速度使用反射和许多其他技巧的依赖关系
运行时调试会更加困难，特别是如果容器在接口和实现该接口的实际组件之间注入代理（想到Spring内置的面向方面的编程）。容器是一个黑匣子，它们并不总是以促进调试过程的任何概念构建的。

总而言之，需要权衡取舍。对于没有很多活动部件的小型项目，没有什么理由使用DI框架。但是，对于已经为您准备了某些组件的更复杂的项目，可以证明该框架是合理的。

[Internet上的随机文章]呢？

该怎么办？它？很多时候，如果您不是以“一种真实的方式”来做事情，人们会变得过分热心，增加了很多限制，并谴责您。没有一种真正的方法。看看您是否可以从本文中提取有用的内容，而忽略您不同意的内容。

总而言之，请自己考虑一下并尝试一下。

“老头子”

尽可能多地学习。在70年代进入工作状态的许多开发人员中，您会发现他们已经学会了不要对许多事情保持教条。他们已经使用了数十年的方法可以产生正确的结果。

我有幸可以使用其中的一些方法，并且它们可以提供一些残酷而诚实的反馈，这些反馈可以使很多感。在他们看到价值的地方，他们将这些工具添加到他们的曲目中。

#2 楼

像大多数模式一样，依赖注入是解决问题的一种方法。因此，首先要问您是否有问题。如果不是这样，那么使用该模式很可能会使代码变得更糟。

如果可以减少或消除依赖性，请首先考虑。在所有其他条件相同的情况下，我们希望系统中的每个组件都具有尽可能少的依赖关系。如果依赖关系消失了，注入或不注入的问题就变得无聊了！

考虑一个模块，该模块从外部服务下载一些数据，对其进行解析，然后执行一些复杂的分析，并将结果写入一份文件。

现在，如果对外部服务的依赖关系进行了硬编码，那么很难对这个模块的内部处理进行单元测试。因此，您可能决定将外部服务和文件系统作为接口依赖项进行注入，这将允许您注入模拟，从而使对内部逻辑进行单元测试成为可能。

但是更好的解决方案是将分析与输入/输出分开。如果将分析提取到没有副作用的模块，则测试起来会容易得多。请注意，模拟是一种代码气味-并非总是可以避免的，但是总的来说，如果您不依赖模拟就可以进行测试会更好。因此，通过消除依赖性，可以避免DI应该缓解的问题。请注意，这样的设计还更好地遵守了SRP。

我要强调的是，DI不一定会促进SRP或其他好的设计原则，例如关注点分离，高内聚/低耦合等。它也可能产生相反的效果。考虑一个A类，该A类在内部使用另一个B类。 B仅由A使用，因此被完全封装，可以视为实现细节。如果将其更改为将B注入到A的构造函数中，那么您已经暴露了该实现的细节，现在有关此依赖项以及如何初始化B的知识，B的生存期等必须分别存在于系统中的其他位置。因此，您的整体架构较差，而且存在泄漏隐患。

另一方面，在某些情况下，DI确实很有用。例如，对于具有记录器之类的副作用的全局服务。

问题在于模式和体系结构本身成为目标而不是工具成为目标。只是问“我们应该使用DI吗？”有点像把马车推到马前。您应该问：“我们有问题吗？”和“解决此问题的最佳解决方案是什么？”

您的问题的一部分归结为：“我们是否应该创建多余的接口来满足模式的需求？”您可能已经意识到了答案-绝对不是！否则，任何人告诉您都在试图向您出售产品-可能是昂贵的咨询时间。仅当接口表示抽象时，它才有价值。仅模仿单个类的表面的接口称为“头接口”，这是已知的反模式。

#3 楼

根据我的经验，依赖项注入有许多缺点。首先，使用DI不能像宣传的那样简化自动化测试。使用接口的模拟实现对类进行单元测试，可以验证该类如何与接口交互。也就是说，它使您可以单元测试被测类如何使用接口提供的协定。但是，这提供了更大的保证，即可以保证被测类在接口中的输入是预期的。它几乎不能保证测试中的类会像预期的那样响应接口的输出，因为它几乎是通用的模拟输出，它本身会受到错误，过分简化等的影响。简而言之，它不能让您验证该类在接口的实际实现中是否会按预期方式运行。

其次，DI使得导航代码变得更加困难。当尝试导航到用作函数输入的类的定义时，接口可以是从小麻烦（例如，只有一个实现的地方）到主要的时间槽（例如，使用像IDisposable这样的过于通用的接口）的任何东西尝试查找正在使用的实际实现时。这可以使诸如“我需要在打印此日志记录语句之后立即发生的代码中修复空引用异常”这样的简单练习变成一天的工作。

第三，DI和框架的使用是一把双刃剑。它可以大大减少常规操作所需的样板代码量。但是，这是以需要特定DI框架的详细知识来理解这些通用操作如何实际连接在一起为代价的。要了解如何将依赖项加载到框架中并在框架中添加新的依赖项以进行注入，可能需要阅读大量的背景资料并遵循有关该框架的一些基本教程。这会将一些简单的任务变成相当耗时的任务。

#4 楼

我遵循Mark Seemann从“ .NET中的依赖注入”的建议-推测。

当您具有“易失性依赖”时，应使用DI。

因此，如果您认为将来可能有多个实现，或者实现可能会发生变化，请使用DI。否则，new可以。

#5 楼

我已经在一些答案中提到了我最大的关于DI的烦恼，但是在这里我将对其进行扩展。 DI（因为今天大多数情况下都是使用容器等完成的），确实损害了代码的可读性。可以说，代码可读性是当今大多数编程创新背后的原因。就像有人说的那样-编写代码很容易。阅读代码很难。但这也非常重要，除非您正在编写某种微小的一次性写入实用程序。

DI在这方面的问题在于它不透明。容器是一个黑盒子。对象只是从某个地方出现而您却不知道-谁构造它们以及何时构造？什么传递给构造函数？我要与谁共享此实例？谁知道...

当您主要使用接口时，IDE的所有“转到定义”功能都会烟消云散。要在不运行程序的情况下追踪程序的流程是非常困难的，只是一步一步地查看在该特定位置仅使用了WHICH接口实现。有时会有一些技术障碍阻止您逐步执行。而且即使可以，如果涉及到遍历DI容器的扭曲肠子，整个事务很快也会令人沮丧。

要有效地使用使用DI的一段代码，您可以必须熟悉它，并且已经知道去哪里。

#6 楼

快速启用切换实现（例如，用DbLogger代替ConsoleLogger）。

虽然一般来说DI当然是一件好事，但我建议不要盲目使用它。例如，我从不注入记录器。 DI的优点之一是使依赖关系明确而明确。将ILogger列为几乎每个类的依存关系没有意义-只是混乱。记录器的责任是提供所需的灵活性。我所有的记录器都是静态的final成员，当我需要非静态的记录器时，我可以考虑添加一个记录器。

增加类的数量

这是给定缺点DI框架或模拟框架，而不是DI本身。在大多数地方，我的课程取决于具体的课程，这意味着需要零样板。 Guice（一个Java DI框架）默认将一个类与其自身绑定，而我只需要在测试中重写绑定（或手动进行绑定）。

创建不必要的接口

我仅在需要时创建接口（这种情况很少见）。这意味着有时候我必须用一个接口替换所有出现的类，但是IDE可以为我做这件事。

只有一个实现时，我们应该使用依赖注入吗？

是的，但要避免增加任何样板。

我们应该禁止创建除语言/框架对象之外的新对象吗？

否。值（不可变的）和数据（可变的）类将很多，在这些实例中，实例被创建并传递，并且在注入它们时毫无意义，因为它们从未存储在另一个对象中（或仅存储在另一个对象中）。在其他类似的对象中）。
对于它们，您可能需要注入工厂，但是大多数情况下，这是没有意义的（例如@Value class NamedUrl {private final String name; private final URL url;}；您实际上不需要这里的工厂，也没有什么要注入）。

如果我们不打算对特定的类进行单元测试，那么注入单个实现是一个坏主意（假设我们只有一个实现，因此我们不想创建“空”接口）？

IMHO只要它不会导致代码膨胀就可以了。请注入依赖项，但不要创建接口（也不要创建疯狂的配置XML！），因为稍后您可以轻松地进行操作。
实际上，在我当前的项目中，有四个类（数百个类），其中我决定从DI中排除它们，因为它们是在很多地方使用的简单类，包括数据对象。

大多数DI框架的另一个缺点是运行时开销。可以将其转移到编译时（对于Java，有Dagger，对其他语言一无所知）。
另一个缺点是，魔术无处不在，可以进行调整（例如，使用Guice时我禁用了代理创建） 。

#7 楼

我必须说，我认为整个依赖注入概念都被高估了。

DI是现代等同于全球价值的东西。您要注入的东西是全局单例和纯代码对象，否则，您将无法注入它们。为了使用给定的库（JPA，Spring Data等），大多数情况下会强制使用DI。在大多数情况下，DI为培育和培养意大利面条提供了理想的环境。

老实说，测试类的最简单方法是确保以一种可以覆盖的方法创建所有依赖项。 。然后创建一个从实际类派生的Test类，并重写该方法。

然后实例化Test类并测试其所有方法。你们中的某些人不清楚这一点-您正在测试的方法属于所测试类的方法。所有这些方法测试都在单个类文件中进行-与被测类关联的单元测试类。这里的开销为零-这是单元测试的工作方式。

在代码中，这个概念看起来像这样...

class ClassUnderTest {

   protected final ADependency;
   protected final AnotherDependency;

   // Call from a factory or use an initializer 
   public void initializeDependencies() {
      aDependency = new ADependency();
      anotherDependency = new AnotherDependency();
   }
}

class TestClassUnderTest extends ClassUnderTest {

    @Override
    public void initializeDependencies() {
      aDependency = new MockitoObject();
      anotherDependency = new MockitoObject();
    }

    // Unit tests go here...
    // Unit tests call base class methods
}

结果与使用DI完全相同-也就是说，将ClassUnderTest配置为进行测试。

唯一的区别是此代码完全简洁，完全封装，易于编码，易于理解，速度更快，使用的内存更少，不需要替代配置，不需要任何框架，永远不会成为4页（WTF！）堆栈跟踪的原因，该堆栈跟踪完全包含您编写的ZERO（0）类，对于从初学者到Guru甚至只有一点点OO知识的人来说都是显而易见的（您会认为，但会弄错了）。

话虽如此，我们当然不能使用它-它太明显了，不够时髦。

归根结底，我对DI的最大担忧是我看到的那些项目惨遭失败，所有这些都是庞大的代码库，其中DI是将所有内容结合在一起的粘合剂。 DI不是一种体系结构-它实际上仅在少数情况下才有意义，其中大多数情况都是为了使用另一个库（JPA，Spring Data等）而被强制执行。在大多数情况下，在一个精心设计的代码库中，DI的大多数使用将在您日常开发活动发生的水平以下进行。

#8 楼

确实，您的问题归结为“单元测试不好吗？”

要插入的替代类的99％是支持单元测试的模拟。

如果不使用DI进行单元测试，就会遇到如何获取类以使用模拟数据或模拟服务的问题。可以说“逻辑的一部分”，因为您可能没有将其分离为服务。

还有其他方法可以做到这一点，但是DI是一种很好且灵活的方法。一旦将其用于测试，您几乎会被迫在任何地方使用它，因为您需要其他代码，即使是所谓的“穷人的DI”也可以实例化具体类型。

很难想象有如此糟糕的缺点，以至于单元测试的优势不堪重负。