为什么dynamic语言不需要IOC容器?

有人在“羊群规范”播客第68号http://herdingcode.com/?p=231上说,国际奥委会的容器没有Python或Javascript的地方,或者说是这个词的意思。 我假设这是传统的智慧,它适用于所有的dynamic语言。 为什么? 什么是dynamic语言,使IOC容器不必要?

IoC提供了一种机制来打破当一个对象在另一个类上调用“new”时所获得的耦合。 这种耦合将调用对象与其实现的任何接口的实例化实现联系起来。

在静态语言中,当你通过名字引用一个类(在它上面调用new )时,没有任何歧义。 这是对特定课程的紧密结合

在dynamic语言中调用new X是一个占位符,用于“在执行时实例化任何定义为X类”。 这是一个宽松的耦合 ,因为它只与名字X

这种细微的差别意味着在dynamic语言中,通常可以改变X是什么,所以关于实例化哪个类的决定在调用类之外仍然是可修改的。

但是,我个人觉得IoC有两个好处,我不能依靠dynamic语言来实现注入。

通过构造函数传递依赖关系的一个副作用是,最终得到的“构build块”类是非常分离的,可重用的并且易于testing。 他们不知道他们打算使用什么样的环境,所以你可以在整个地方重复使用它们。

另一个结果是有明确的代码做布线。 正确地做了这个干净地表示你的应用程序的结构,它分解成子系统和生命周期。 这使得人们明确地决定他们想把哪个生命周期或者子系统与他们的class级联系起来(在编写布线代码的时候),并且在写class的时候专注于对象的行为。

就像JörgW Mittag说的那样。 “那些工具是不必要的,devise原则不是。” 我相信这是不必要的,但是做得对,还是有价值的。

我有不同的意见。 我认为IOC容器肯定在dynamic语言中起作用。

我不同意这样一种观点,即dynamic语言不需要一个结构清晰的对象组合。 或者说一个dynamic语言“提供”了相同的function。

国际奥委会容器只是一个pipe理这个组织的工具。

即使在dynamic语言中,我也想将各个组件“连线”在一起。 不要在这些组件之间做出硬性依赖关系。 或者甚至可能没有指定这些组件的实际实现类。

我同意上面的答案,但是我认为我也会在这方面对testing进行一点研究:

在子系统之间存在交互的复杂系统中,dependency injection是我知道进行unit testing的最佳方法。

如果你有一个逻辑单元X,它与逻辑单元Y有已知的交互,你可以创build一个具有预定义行为的MockY,并明确地testingX的逻辑。

没有dependency injection,写testing是一场噩梦。 你不能得到很好的代码覆盖率。 一些框架(例如django)通过转换模拟数据库实例来交谈testing等来解决这个问题,但这基本上是一个很糟糕的解决scheme。

应该有两种testing:

  • 在任何环境下运行的unit testing,并testing各个代码单元的逻辑。
  • 集成/functiontesting,testing组合的应用程序逻辑。

现在来回答这个问题:IoC。 IoC有什么好处? 这对于一些事情是很方便的,但是使它更容易地使用dependency injection是非常好的:

 // Do this every time you want an instance of myServiceType var SystemA = new SystemA() var SystemB = new SystemB() var SystemC = new SystemC(SystemA, "OtherThing") var SystemD = new SystemD(SystemB, SystemC) var IRepo = new MySqlRepo() var myService = new myServiceType(SystemD, IRepo) 

进入这个逻辑:

 // Do this at application start Container.Register(ISystemA, SystemA) Container.Register(ISystemB, SystemB) Container.Register(ISystemC, SystemC) Container.Register(ISystemD, SystemD) Container.Register(IRepo, MySqlRepo) Container.Register(myServiceType) // Do this any time you like var myService = Container.resolve(myServiceType) 

现在,为什么我们不能在很多dynamic语言中看到IOC?

我想说的原因是,我们没有看到这些语言的dependency injection。

…那是因为通常他们所做的testing是不存在的。

我听到过各种各样的借口, 与DOM交互使得testing变得困难,我的代码很简单,不需要testing,dynamic语言不需要unit testing,因为它们很棒,而且很有performance力。

这都是无稽之谈。

没有unit testing或者代码覆盖率低的unit testing的项目是没有借口的。

…但是,我所见过的javascript和python项目的数量是惊人的(select这两个具体只是因为它们是一个感兴趣的领域,而且我看到了比其他项目更多的项目),没有IoC DI,毫不奇怪,没有testing。

在guice网站上有一篇关于DI的优秀文章: http : //code.google.com/p/google-guice/wiki/Motivation

dynamic语言没有任何解决这些问题的方法。

概要:

  • IoC对事物有用,但主要用于实施DI
  • IoC 不是 xmlconfiguration文件。 > _ <
  • DI对于testing是有用的
  • 缺乏IOC表明没有DI,这表明没有好的testing。
  • 使用IoC。

因为他们已经build立在语言。

一个IoC容器提供了两件事情:

  • dynamic绑定
  • 一个dynamic的语言(通常是一个令人难以置信的糟糕的语言,build立在XML之上或者在Java注释/ .NET属性之上的新版本中)

dynamic绑定已经是dynamic语言的一部分,dynamic语言已经是一种dynamic语言。 因此,IoC容器根本没有意义:语言已经是IoC容器。

另一种看待它的方法是:一个IoC容器允许你做什么? 它可以让你独立的组件,并将它们连接在一起成为一个应用程序,没有任何组件知道任何关于对方。 有一个独立的布线连接到一个应用程序的名字:脚本! (这几乎就是脚本的定义。)许多dynamic语言碰巧在脚本编写上也相当不错,因此它们非常适合作为IoC容器。

请注意,我不是在谈论dependency injection或控制反转。 DI和IoC在dynamic语言中与静态语言一样重要,原因完全相同。 我在说的是IoC容器和DI框架。 那些工具是不必要的, devise原则不是。

IOC容器的主要function之一是可以在运行时自动将模块“连接”在一起。 在dynamic语言中,你可以很容易地做到这一点,没有任何幻想的基于reflection的逻辑。 但是,IOC容器是很多人理解的有用模式,使用相同的devise风格有时会带来一些好处。 看到这篇文章的另一个观点。

IoC提供了一种机制来打破当一个对象在另一个类上调用“new”时获得的耦合。

这是对IoC的天真观点。 通常IoC也解决:

  • 依赖关系parsing
  • 自动组件查找和初始化(如果您在IoC中使用'require',则出现错误)
  • 不仅适用于单身,也适用于dynamic范围
  • 99.9%的时间对开发者来说是无形的
  • 消除了对app.config的需求

全文你低估了IoC的力量

我相信IoC容器在大型JavaScript应用程序中是必需的。 您可以看到一些stream行的JavaScript框架包含一个IoC容器(例如Angular $injector )。

我开发了一个名为InversifyJS的IoC容器,您可以在http://inversify.io/上了解更多信息。;

那里的一些JavaScript IoC容器声明了要注入的依赖关系,如下所示:

 import Katana from "./entitites/katana"; import Shuriken from "./entitites/shuriken"; @inject(Katana, Shuriken) // Wrong as Ninja is aware of Katana and Shuriken! class Ninja { constructor(katana: IKatana, shuriken: IShuriken) { // ... 

这种方法的好处是没有string文字。 坏消息是我们的目标是实现解耦,而且我们只是在文本中join了对Katana和Shuriken硬编码引用,而这个引用并不是真正的解耦。

InversifyJS为您提供真正的解耦。 ninja.js文件永远不会指向katana或shuriken文件。 但是,它将指向可接受的接口(在devise时)或string文字(在运行时),因为这些是抽象的, 取决于抽象是DI是什么。

 import * as TYPES from "./constants/types"; @inject(TYPES.IKATANA, TYPES.ISHURIKEN) // Right as Ninja is aware of abstractions of Katana and Shuriken! class Ninja { constructor(katana: IKatana, shuriken: IShuriken) { // ... 

InversifyJS内核是应用程序意识到生命周期和依赖性的唯一元素。 我们build议在名为inversify.config.ts的文件中执行此inversify.config.ts ,并将文件存储在包含应用程序源代码的根文件夹中:

 import * as TYPES from "./constants/types"; import Katana from "./entitites/katana"; import Shuriken from "./entitites/shuriken"; import Ninja from "./entitites/ninja"; kernel.bind<IKatana>(TYPES.IKATANA).to(Katana); kernel.bind<IShuriken>(TYPES.ISHURIKEN).to(Shuriken); kernel.bind<INinja>(TYPES.ININJA).to(Ninja); 

这意味着应用程序中的所有耦合发生在一个独特的地方inversify.config.ts文件。 这真的很重要,我们将用一个例子来certificate它。 让我们想象一下,我们正在改变游戏的难度。我们只需要去inversify.config.ts并更改Katana绑定:

 import Katana from "./entitites/SharpKatana"; if(difficulty === "hard") { kernel.bind<IKatana>(TYPES.IKATANA).to(SharpKatana); } else { kernel.bind<IKatana>(TYPES.IKATANA).to(Katana); } 

你不需要改变忍者文件!

要支付的价格是string文字,但是如果在包含常量的文件( 如Redux中的动作 )中声明所有string文字,此价格可以减轻。 好消息是,将来string文字最终可能由TS编译器生成 ,但目前在TC39委员会手中。

你可以在这里尝试一下 。

IoC容器真的允许在静态types,过程/ OO语言中的组合层。

这个构图层在dynamic语言(比如Python或者Javascript)中相对自然地存在(认为Javascript主要基于Scheme)。

你可能会提出一个很好的论点,即IoC容器只是解释器模式的一个泛化。

Herding Code 82 (6/6/10)比较了Ruby和.NET,并详细讨论了.NET需要比Ruby更多IOC / DI的程度。