使用依赖注入的缺点是什么？ [关闭]

#1 楼

有两点：


DI增加了复杂性，通常是通过增加类的数量来增加责任的分离，这并不总是有益的。
您的代码将是（某种程度上）耦合到您使用的依赖项注入框架（或更笼统地说，您决定执行DI模式的方式）
执行类型解析的DI容器或方法通常会造成轻微的运行时代价（非常微不足道，但确实存在）

通常，去耦的好处使每个任务更易于阅读和理解，但是却增加了编排更复杂任务的复杂性。

#2 楼

与面向对象的编程，样式规则以及几乎所有其他内容经常遇到的相同基本问题。实际上，很可能会做太多的抽象工作，增加过多的间接访问，并且可能过度地在错误的地方过度应用良好的技术。

您应用的每种模式或其他构造带来了复杂性。抽象和间接分散信息，有时将无关紧要的细节移开，但有时也使得更难于准确了解正在发生的事情。您所应用的每条规则都带来了灵活性，排除了可能只是最佳方法的选择。

关键是编写能起作用，健壮，易读和可维护的代码。您是软件开发人员，而不是象牙塔的构建者。

相关链接

http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx
< http://www.joelonsoftware.com/articles/fog0000000018.html



可能是最简单的依赖项注入形式（不要笑）是一个参数。从属代码依赖于数据，并且通过传递参数的方式来注入数据。

是的，它很愚蠢，并且没有解决依赖项注入的面向对象问题，但是函数式程序员会告诉您（如果您具有一流的函数），这是您唯一需要的依赖项注入。这里的重点是举一个简单的例子，并说明潜在的问题。

让我们使用这个简单的传统函数-C ++语法在这里并不重要，但我必须以某种方式将其拼写...

void Say_Hello_World ()
{
  std::cout << "Hello World" << std::endl;
}

我有一个要提取并注入的依赖项-文本“ Hello World”。足够容易...

void Say_Something (const char *p_text)
{
  std::cout << p_text << std::endl;
}

那比原来的那么僵硬？好吧，如果我决定输出应为Unicode怎么办。我可能想从std :: cout切换到std :: wcout。但这意味着我的字符串必须是wchar_t，而不是char。要么必须更改每个调用者，要么（更合理地说）是，旧的实现被替换为适配器，该适配器转换字符串并调用新的实现。

在那里的维护工作就不会了。

如果看起来很琐碎，请从Win32 API看一下这个真实函数...

http：/ /msdn.microsoft.com/zh-CN/library/ms632680%28v=vs.85%29.aspx

要处理的12个“依赖项”。例如，如果屏幕分辨率变得非常高，也许我们将需要64位坐标值-以及另一个版本的CreateWindowEx。是的，已经有一个较旧的版本存在，大概是在幕后映射到了较新的版本...

http://msdn.microsoft.com/zh-cn/library/ ms632679％28v = vs.85％29.aspx

那些“依赖项”不只是原始开发人员的问题-使用该接口的每个人都必须查找依赖项是什么，它们如何指定它们的含义以及它们的含义，并弄清楚该应用程序应做什么。在这里，“合理的默认值”可以使生活变得更加简单。

面向对象的依赖注入在原理上没有什么不同。无论是在源代码文本中还是在开发人员时，编写类都是一项开销，并且如果根据某些相关对象规范编写该类以提供相关性，则即使有需要，该相关对象也被锁定为支持该接口。替换该对象的实现。

所有这些都不应该被视为声称依赖注入是不好的-远非如此。但是，任何好的技术都可能在错误的地方过度使用。正如不是每个字符串都需要提取出来并转化为参数一样，并不是每个低级行为都需要从高级对象中提取出来并转化为可注入的依赖关系。

#3 楼

这是我自己的初步反应：任何模式基本上都有相同的缺点。


学习需要时间，如果误解会导致弊大于利
采取极端措施可能比证明收益合理得多。

#4 楼

控制反转的最大“缺点”（不是完全的DI，但足够接近）是，它倾向于消除只看算法概述的问题。不过，这基本上就是在将代码解耦后会发生的事情-能够在一个地方查看是紧密耦合的产物。

#5 楼

在过去的6个月中，我一直在广泛使用Guice（Java DI框架）。总体而言，我认为它很棒（尤其是从测试的角度来看），但存在某些缺点。最值得注意的是：



代码可能变得更难以理解。依赖注入可以以非常有创意的方式使用。例如，我刚遇到了一些代码，这些代码使用自定义批注注入特定的IOStreams（例如：@ Server1Stream，@ Server2Stream）。尽管这样做确实有效，但我承认它具有一定的优雅性，但它使理解Guice注入成为理解代码的先决条件。

学习项目时的学习曲线更高。这与第1点有关。为了了解使用依赖注入的项目的工作方式，您需要了解依赖注入模式和特定框架。当我开始目前的工​​作时，我花了很多时间来迷惑Guice在幕后所做的事情。

构造函数变得很大。尽管可以使用默认构造函数或工厂在很大程度上解决此问题。

错误可以被混淆。我最近的例子是我在两个标志名称上发生了冲突。 Guice默默地吞下了错误，并且我的标志之一未初始化。

错误被推送到运行时。如果您错误地配置了Guice模块（循环引用，绑定错误，...），则在编译期间不会发现大多数错误。相反，当程序实际运行时会暴露错误。

现在我抱怨了。让我说，我将继续（愿意）在我当前的项目中，很可能在下一个项目中使用Guice。依赖注入是一种非常强大的模式。但这肯定会造成混淆，您几乎肯定会花一些时间在您选择的任何依赖注入框架上进行诅咒。

此外，我也同意其他海报认为依赖注入会被过度使用。

#6 楼

我认为这样的列表不存在，但是请尝试阅读这些文章：


DI可以掩盖代码（如果您使用的不是良好的IDE）
根据Bob叔叔的说法，滥用IoC可能会导致错误的代码。
需要注意过度设计和产生不必要的多功能性。

#7 楼

没有任何DI的代码就存在陷入Spaghetti代码的众所周知的风险-有些症状是类和方法太大，做得太多并且不容易更改，分解，重构或测试。 >
大量使用DI的代码可以是Ravioli代码，其中每个小类都像一个单独的馄饨块-它做一件小事情，并且遵循单一责任原则，这很好。但是单独查看类很难看到系统整体的功能，因为这取决于所有这些小部分如何组合在一起，这很难看到。它看起来像一大堆小东西。

通过避免大型类中大量耦合代码的意大利面条式复杂性，您冒着另一种复杂性的风险，该类中有许多简单的小类，并且它们之间的交互非常复杂。

我认为这不是致命的缺点-DI仍然非常值得。某种程度上只做一件事的小饺子馄饨风格可能是好的。即使过多，我也认为这不是意大利面条代码的坏处。但是要意识到它可能采取的措施过于严格，这是避免它的第一步。请按照链接讨论如何避免这种情况。

#8 楼

如果您有自己开发的解决方案，则依赖关系就在构造函数中浮出水面。或作为方法参数，也不太难发现。尽管将框架管理的依赖项放到了极致，但是它开始看起来就像魔术一样。
但是，在太多的类中拥有太多的依赖项则清楚地表明您是在弄糟类结构。因此，以某种方式进行依赖项注入（本地生成或由框架管理）可以帮助解决明显的设计问题，而这些问题本可以隐藏在黑暗中。

为更好地说明第二点，以下摘录自我全心全意地相信这篇文章（原始资料）是构建任何系统而不仅仅是计算机系统的根本问题。

假设您要设计一个大学校园。您必须将一些设计委托给学生和教授，否则物理大楼对物理人员而言将无法正常工作。没有任何一位建筑师对物理学家需要自己做的事情了解得足够多。但是您不能将每个房间的设计委托给它的占用者，因为那样您会得到一堆巨大的瓦砾。
如何在较大的层次结构的各个层次上分配设计责任，同时又保持一致性和整体设计的和谐？这是Alexander试图解决的体系结构设计问题，但这也是计算机系统开发的基本问题。

DI可以解决这个问题吗？不会。但是，它确实可以帮助您清楚地知道是否要将设计每个房间的责任委托给其居住者。

#9 楼

您只是通过实现依赖注入而没有实际将其解耦来使代码解耦的错觉。我认为这是DI最危险的事情。

#10 楼

让我对DI感到困惑的一件事是，假设所有注入的对象都易于实例化并且不产生副作用-OR-依赖关系使用得如此频繁，以至于它超过了任何关联的实例化成本。

当消费类中不经常使用依赖项时，这可能很重要。例如IExceptionLogHandlerService之类的东西。显然，此类服务很少在类中被调用（希望:)）-大概仅在需要记录的异常时才调用。但是规范的构造函数注入模式...

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

     ...
End Class

...要求提供此服务的“实时”实例，这会破坏成本/副作用需要到那里。不太可能，但是如果构造此依赖项实例涉及服务/数据库命中，配置文件查找或锁定资源直到处置该怎么办？如果此服务是按需构建，位于服务所在地或由工厂生成的（都有自己的问题），那么您将仅在必要时承担构建成本。

现在，这是一种普遍接受的软件设计原则，即构造一个对象很便宜并且不会产生副作用。尽管这是一个很好的概念，但并非总是如此。但是，使用典型的构造函数注入基本上要求是这种情况。意味着在创建依赖项的实现时，必须在设计时考虑到DI。也许您本可以使对象构造的成本更高，以在其他地方获得收益，但是如果要注入此实现，则可能会迫使您重新考虑该设计。

顺便说一句，某些技术可以通过允许延迟注入已注入的依赖项来减轻此确切问题，例如，提供一个Lazy<IService>实例作为依赖项。这将改变您的从属对象的构造函数，从而使您更加意识到实现细节，例如对象构造费用，这可能也是不希望的。

#11 楼

这更像是挑剔。但是依赖项注入的缺点之一是，它使开发工具难以推理和导航代码。

具体来说，如果您按住Control-Click / Command-Click的方法调用代码，它会将您带到接口上的方法声明而不是具体的实现。

这实际上是松散耦合代码（由接口设计的代码）的缺点，甚至适用于如果您不使用依赖注入（即，即使您只是使用工厂）。但是依赖注入的出现真正促使了松散耦合代码的普及，所以我想提一提。

此外，松散耦合代码的好处远不止于此，因此我称之为顽皮。尽管我花了很长时间才知道，如果尝试引入依赖项注入，这可能会带来一些挫折。

实际上，我敢于猜测每个“缺点”，您可以找到依赖注入，远远超过了它的许多缺点。

#12 楼

基于构造函数的依赖注入（无需借助神奇的“框架”）是一种构造OO代码的干净而有益的方法。在我见过的最好的代码库中，与马丁·福勒（Martin Fowler）的其他前同事一起工作了数年之后，我开始注意到以这种方式编写的大多数好的类最终都只有一个doSomething方法。

不利的一面是，一旦意识到这只是一种将闭包作为类来编写闭包的长途OO方式，以便获得功能编程的好处，那么编写OO代码的动机就会迅速消失。

#13 楼

我发现构造函数注入会导致庞大的丑陋构造函数，（并且我在代码库中都使用了它-也许我的对象太细粒度了？）。同样，有时使用构造函数注入会导致可怕的循环依赖关系（尽管这种情况非常罕见），因此您可能会发现自己必须拥有某种就绪状态生命周期，并且必须在更复杂的系统中进行几轮依赖注入。 >
但是，相对于setter注入，我更喜欢使用construtor注入，因为一旦构造了我的对象，我无疑就会知道它处于什么状态，无论是在单元测试环境中还是在某些IOC容器中加载。用一种a回曲折的方式，这就是说我感觉是二传手注射的主要弊端。

（作为旁注，我确实认为整个话题都非常“宗教化”，但是您的里程会开发团队中的技术狂热程度会有所不同！）

#14 楼

如果您使用的是没有IOC容器的DI，那么最大的缺点就是您会很快看到您的代码实际具有多少依赖关系以及所有东西之间的紧密耦合程度。 （“但是我认为这是一个很好的设计！”）自然的过程是向IOC容器过渡，该容器可能需要一点时间来学习和实施（虽然不如WPF学习曲线那么糟糕，但是它不是免费的）要么）。最后的缺点是一些开发人员将开始编写诚实到善良的单元测试，这将需要他们花费一些时间来解决。以前可以在半天之内解决问题的开发人员会突然花两天的时间来弄清楚如何模拟所有依赖项。

类似于Mark Seemann的回答，最重要的是您要花时间成为一个更好的开发人员，而不是将一些代码一起乱搞然后扔出去/投入生产。您的公司宁愿拥有哪一家？只有你能回答。

#15 楼

DI是一种技术或模式，与任何框架都不相关。您可以手动连接依赖项。 DI帮助您实现SR（单一职责）和SoC（关注点分离）。 DI导致更好的设计。从我的观点和经验来看，没有缺点。像使用其他任何模式一样，您可能会出错或滥用它（但是在DI的情况下很难）。

如果您将DI作为原理引入到旧版应用程序中，则使用框架-您能做的最大的错误就是将其误用作服务定位器。 DI + Framework本身很棒，并且在我看到的任何地方都能使它变得更好！从组织的角度来看，每个新流程，新技术，新模式...都存在常见问题：


您必须训练团队
您必须更改应用程序（其中包括风险）

一般来说，您必须花费时间和金钱，除此之外，真的没有缺点！

#16 楼

代码可读性。由于依赖关系隐藏在XML文件中，因此您将无法轻松弄清楚代码流。

#17 楼

两件事：


它们需要额外的工具支持来检查配置是否有效。

例如，IntelliJ（商业版）支持检查有效性Spring配置，并将标记错误，例如配置中的类型冲突。没有这种工具的支持，您将无法在运行测试之前检查配置是否有效。

，这就是“蛋糕”模式（如Scala社区所知）是一种原因的原因之一。好主意：组件之间的接线可以通过类型检查器检查。使用注释或XML并没有带来好处。


它使程序的全局静态分析变得非常困难。

像Spring或Guice这样的框架使它变得困难。静态确定容器创建的对象图的外观。尽管它们在容器启动时创建了一个对象图，但是它们没有提供有用的API，这些API描述了/ would /将要创建的对象图。

#18 楼

当您不断采用技术解决静态类型问题时，静态类型语言的预期好处似乎已大大减少。我刚刚采访的一家大型Java商店正在通过静态代码分析来映射其构建依赖关系...必须解析所有Spring文件才能有效。

#19 楼

因为IoC容器应该以适当的方式解决依赖关系，并且有时需要进行多次迭代，所以它可以增加应用程序的启动时间。