我和我的同事之一在依赖注入方面进行了激烈的辩论,并意识到我不完全知道关于这个问题的所有事实.
所以,采取这个代码(只是你知道,我们正在使用Castle Windsor)
IPlayerService service = Container.Resolve<IPlayerService>();
上面的代码显然是DI使用IoC的一个例子.
但是,请参阅下面的代码(更新：假设我通过构造函数传递所有外部依赖项)：
var playerClient = new PlayerClient(); var playerSkinClient = new PlayerSkinClient(); IPlayerService service = new PlayerService(playerClient,playerSkinClient);
我的论点是,上面的代码是DI模式的一个例子,DI可以在没有IoC的情况下存在.
现在,我的同事并没有完全不同意我的意见,但他说上述代码并不是涉及DI的任何模式的例子.
所以,DI可以作为一个没有任何额外框架的模式吗？
>如果是,上面的代码是一个例子吗？
>最后,定义一个DI模式,如果存在,没有容器的概念.
UPDATE
今晚晚些时候我会详细介绍一下答案和评论,但是只是想感谢大家对于迄今为止的深思熟虑的答案和意见！
在Java世界中,依赖注入通常涉及框架,容器等.但是并不需要所有的机器.
原文链接：https://www.f2er.com/javaschema/281837.html依赖注入的本质是一个能够被赋予它所依赖的对象的类,而不是使它们在实现中被硬编码.如果可以从类外部“注入”这些“依赖关系”,那么就有依赖注入.框架可能是一个很好的方法,但不是必需的.
在Python世界中,没有关于依赖注入的框架文化,所以很多程序员想知道什么是大惊小怪.对他们来说,DI是“只是”能够将对象或类传递给构造函数.
回答你的具体问题：
>是的,DI可以在没有框架的情况下完成.>是的,上面的代码是一个例子：PlayerService不知道PlayerClient或PlayerSkinClient来自哪里.他们被注入课堂.请注意,其他人回答了这个“否”.>见上文.
