初学 jvm 语言，依赖注入 和 一个实例变量传递给另外的对象 有什么区别？

[leyle]

搜索了一圈，基本都在说如何实现依赖注入，看来看去都是把一个实例变量传递给另外一个对象。
以前从没接触过 jvm 类的语言，对 jvm 的很多概念都感觉头大。

这个依赖注入和传递实例变量给另外一个对象，有什么具体的区别？

[p2pCoder]

容器与解耦

[jimrok]

如果能实现依赖注入，相当于没有写死一个实现。这样，测试时候可以用个假对象来模拟接口进行测试。生产时候，再替换一个实现。

[xiaoshenke]

没有区别

[skypyb]

可以说是一个极致的解耦了，你的使用方和实体之间没有任何交互，其创建与销毁都归于第三方。

[jinhan13789991]

依赖注入就是 set 啊

[111qqz]

2 个小时刚了解到这个概念的菜鸡觉得，好像没什么区别？

[lockelee]

找一个相对复杂系统，你不用依赖注入框架，自己维护一下对象关系改造试一试。
然后你就知道为什么要依赖注入了。
很多工程问题已经被框架解决了，但是新人学习的时候其实都没有碰到过这些问题，所以就可能会不太能感知为什么要这么做吧。

[STRRL]

可以这么理解：注入就是在你需要的时候“自动” set 进去。。

[lhx2008]

spring 本质上就是一个保存对象单例的 map，根据不同条件取出来。
就好像，原始社会需要以物易物，地要自己种。现在是直接去市场买，就这么简单

[zn]

你说的情况没区别，实际上都是属于依赖注入的范畴。

依赖注入的核心思想是：如果需要用到其他类的对象实例，不在自己类里面 new 其他类的对象实例，而是通过其他方法传对象实例进去。

所以你的做法实际上就是属于依赖注入。



另外，我想，你实际上想问的是依赖注入对象与自己 new 对象有什么区别吧？

[lhx2008]

还有这并不是 jvm 的锅，其他语言也很常见

[carlclone]

传递进去的类型判断是一个接口，而不是具体的类 ， 这样就能看出区别了
可以自由更换接口实现，不需要去修改代码
扩展性上的考量

[Cbdy]

依赖注入的实质是代码生成，生成样板代码

[ixiaohei]

解耦；软件工程里面的概念。方便软件后续维护；这个工程做多了，做大了就会越来越有感觉..

[earendil1412]

依赖注入不只是 JVM 的东西，而是面向对象的东西。
为什么只在 JVM 上见到依赖注入？因为别的语言 IOC 容器太差劲了

[wenzhoou]

我不认同解耦的说法。我认同 @zn 的说法。 我认为它就是替代在方法调用的时候不要去 new。因为开销很大。

[popbones]

我理解变量传递是依赖注入的一种形式。根据维基百科的解释，依赖注入的核心理念在于“客户”对象获得一个“服务”对象，而不是由”客户“对象去发现或者构建”服务“对象。这里的”客户“和”服务“对象只是个相对的抽象概念，用来表述”客户“对象需要使用 /依赖于”服务“对象提供的”服务“。

而究竟如何将”服务“对象提供给”客户“对象，可以有很多不同的形式，比如在”客户“对象的构造函数传入，或通过成员变量、属性、Setter、Interface 或者 delegate 来实现都是可以的。重点是”客户“对象不需要知道如何构建”服务“对象。

[fox0001]

自动与手动的区别…

[yinaqu]

@wenzhoou 解耦是一个方面，控制反转（ IOC ）就是不要让用户代码自己去注入依赖。你说的替代 new 的说法不对，不用容器也不一定需要每次都 new，工厂+单例不就行了；况且容器也可以每次都 new （ prototype 模式），只不过大多数情况下我们都用容器的 singleton 模式而已

[jimrok]

@wenzhoou
@yinaqu 很同意你的说法，就是不要自己去管理依赖的对象，而是让容器去管理，这样容器可以在运行时给你把手枪换成火炮。如果你自己 new 一个手枪，你就永远依赖这个手枪。不过要注意，不要什么代码都弄成 IOC 管理，非常难理解，因为不知道运行期被注入的是什么对象。尽量模块化依赖，模块内部不要再搞 IOC。

[SoloCompany]

和 jvm 没什么关系

依赖注入本质上就是一种解耦
生产（工厂）
消费（业务）
控制（框架）

如果不使用依赖注入，就是生产和消费是混在一起的，消费直接对生产依赖
解耦后，消除了消费对生产的直接依赖，提高了可重用性
但一般不是为了业务逻辑重用，而是更容易实现和测试