Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/design-patterns/2.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Design patterns 何时不使用IoC和DI?_Design Patterns_Dependency Injection_Inversion Of Control_Methodology - Fatal编程技术网

Design patterns 何时不使用IoC和DI?

Design patterns 何时不使用IoC和DI?,design-patterns,dependency-injection,inversion-of-control,methodology,Design Patterns,Dependency Injection,Inversion Of Control,Methodology,我看到很多文章说IoC和DI有多伟大,但没有一篇文章提到为什么它不那么伟大,因为它会使代码变得更复杂。我还看到,IoC不应该出现在代码的核心部分,而应该更多地出现在库和插件中。文章通常只是对这两种模式如何使代码变得更复杂的一个小的参考,但没有太多的细节。这就是我的问题——您具体应该在哪里不使用这些模式 这是一个很好的线程:。如果你往下看,有一篇关于拼写检查器的帖子,还有一篇关于如果只有一个拼写检查器,IoC可能没有什么用处的帖子。作为一个一般性的指导原则,IoC是否应该被使用,因为我曾经只有一个

我看到很多文章说IoC和DI有多伟大,但没有一篇文章提到为什么它不那么伟大,因为它会使代码变得更复杂。我还看到,IoC不应该出现在代码的核心部分,而应该更多地出现在库和插件中。文章通常只是对这两种模式如何使代码变得更复杂的一个小的参考,但没有太多的细节。这就是我的问题——您具体应该在哪里不使用这些模式

这是一个很好的线程:。如果你往下看,有一篇关于拼写检查器的帖子,还有一篇关于如果只有一个拼写检查器,IoC可能没有什么用处的帖子。作为一个一般性的指导原则,IoC是否应该被使用,因为我曾经只有一个具体的接口类?意思是,我有一辆摩托车。然后是实现IMyClass的具体MyClassA。我为什么要去那里

如果我有MyClassA、MyClassB和MyClassC,它们都实现了IMyClass,那么这些可能都是国际奥委会的优秀候选人,对吗

从同一条线索,有人知道这篇文章的意思吗:

控制权倒置=婚姻
  • IOC容器=妻子
  • 来自:

    我为什么不使用它?

    你不应该使用倒装句 控制容器,如果您没有 熟悉这些概念,如果您 没有意识到他们试图解决的问题 解决

    另外,取决于尺寸和尺寸 项目的复杂性,国际奥委会 容器可能有点过分了。宁愿 在大中型项目中使用它


    关于您关于只有一个接口实现的问题。使用IoC时,使用接口仍然很有用。对于这些接口,使用mock创建真正的单元测试(不依赖于接口实现是否正常工作)会容易得多。使用IoC的核心是使代码更易于测试。所以,如果你不想测试,或者已经有了一个更好的没有IoC的测试计划,就不要使用IoC

    总之,DI和IoC复杂性的增加是通过更容易测试和更少耦合的代码来实现的。更容易隔离问题并在将来进行更改。你也可以更好地控制它的行为


    我可以看到何时不使用IoC容器(因为它会导致配置开销)。这会发生在小型项目上,您可以手动执行,而不是使用容器。但是我看不出使用DI会有什么损失,除非你不打算测试你的代码……

    关于IoC的抱怨很容易理解:IoC把简单的东西变成了复杂的东西。假设您想对列表中的每个元素(伪代码)执行一些操作:

    本质上,IoC正在将循环迭代的责任转移给其他人。因此,我们的结局更像这样:

    ioc = new IocContainer()
    ioc.register_callback(do_something)
    ioc.go()
    
    请注意,即使在这种简单的形式中,代码也比原来的长。。。这还不包括IocContainer的实现

    然后,以其最奇特的形式,IocContainer可以静态初始化,也可以通过静态Main()函数初始化,或者在其他隐藏的地方初始化,并且register\u callback()函数会根据一些其他代码自动调用,这些代码会迭代一个XML文件,该文件列出了所有do\u something()函数和(有时)甚至列表的内容也需要迭代

    是的,XML文件使您的软件更加可配置!对吗?只需更改一个简单的文本文件,就可以更改列表中的某些操作

    具有讽刺意味的是,您的源代码现在变得越来越长,越来越难理解,它依赖于各种新的、可能有缺陷的库(包括IocContainer和XML解析器),而且您实际上使维护变得更加困难:XML代码比原始的简单源代码循环更难理解和编辑(不管循环是用什么语言编写的)。您对迭代的具体方式(排序还是未排序?深度优先还是广度优先?)的控制也较少,因为IocContainer正在将这一责任从您身上夺走

    对于插件之类的东西,使用IoC是有意义的,因为主应用程序控制执行过程是合乎逻辑的,只要在这里或那里向插件寻求帮助就行了。这被称为“提供挂钩”,比IoC术语的时间要长得多

    对于单元测试(这是我经常看到的)这样的事情,IoC通常是没有帮助的,因为你的测试需要能够模拟各种各样的奇怪情况,而IoC只是不断地阻挠


    IoC的基本假设是加载数据和循环在某种程度上是困难的,需要取消;这个假设是不正确的,因为它无论如何都不会超过几行(或者你可以将它移动到一个单独的函数),即使它确实保存了代码,也会降低您的灵活性。

    是否使用IoC容器不是单个类级别的决定-在任何项目中,您都将拥有由容器创建和不由容器创建的类型

    复杂性权衡如下:

    • 对于少数组件,IoC容器确实会增加一些开销
    • 随着应用程序中组件数量的增加:
      • 如果没有IoC容器,添加新组件或重构将变得越来越困难
      • 对于IoC容器,添加新组件或重构保持不变:您只需要担心正在添加或更改的组件的直接依赖性

    如果您曾经经历过即使是设计良好且维护良好的代码库也会因大小而变得难以管理的现象,那么您已经经历过IoC容器所解决的问题。

    IoC/DI不是技术,而是范例。您的问题类似于问“我什么时候不应该使用面向对象编程?”
    ioc = new IocContainer()
    ioc.register_callback(do_something)
    ioc.go()