Question

依赖注入究竟有什么好处？

我使用过一些 依赖注入框架——但是他们的实现在我看来，就是在使用类似反射的机制！！

不让对象 new 出来，就降低了依赖！

——难道，我写一个简单的 反射类，我就相当于写出了一个 依赖注入框架吗？？？那么 Spring, Castle, Unity 岂不是都SB？？

我只想知道：本来一个反射类可以实现的功能；为什么 那些大型公司会用一个团队来开发！开发出的功能只是 反射！——于是美其名曰 “依赖注入，控制反转”？？

我一直困惑。一个简单的反射为什么说的神乎其技！ 说服我者 追加 35分！！——我在百度知道一向慷慨的！
我正是因为谦逊，所以更愿意相信那些框架 比我的 反射类 强10000倍！！——如果你也说不出强在哪里！你要我怎么愿意被说服！
我也知道，这些大型框架除了 所谓的“依赖注入”之外，还有 调用拦截（AOP）！
再次提升 15积分，求 说服！！！
----------------------------------------------------------------------------------------------
好了，该结贴了！
回答很多，也许是我将 “依赖注入”在 大型框架中的作用看得太大了！也或许自己太愿意相信大型公司的大型框架比自己强很多倍，所以在 感觉自己的 一个类 就可以 做到他们的部分功能时，我不愿意相信他们是简单的！

感谢各位的回答，综合各方回答：
那些大型框架具备 “依赖注入”，AOP(调用拦截)，对象生命周期的控制，其他的对象控制，还有有利于 各种资源的整合！！

感谢 shhyuhan 提到了调用拦截；
感谢 liziride 提到了大型框架的 整合性；
感谢 只懂一点 提到了我提出的问题的局限性；
感谢 ahyyxx222 提到了 Spring 的深层工作原理的一些东西；

悬赏再加上 20分，履行自己的 承诺！——但满意答案只能选一个，所以选择了 liziride 以“整合性”为思想的答案！也感谢其他各位的帮助！

Answer 1

把对象生成放在了XML里定义，所以换一个实现子类将会变成很简单（一般这样的对象都是实现于某种接口的），只要修改XML就可以。这样甚至可以实现对象的热插拨。
依赖注入：

依赖注入就是Spring设计思想中重要的一部分,它是指Ioc或DI,是一个重要的面向对象编程的法则来削减计算机程序的耦合问题.控制反转还有一个名字叫做依赖注入（DependencyInjection）.简称DI.
IoC亦称为“依赖倒置原理”("DependencyInversionPrinciple")。差不多所有框架都使用了“倒置注入(Fowler2004)技巧，这可说是IoC原理的一项应用。SmallTalk，C++,Java或各种.NET语言等面向对象程序语言的程序员已使用了这些原理。
应用控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用，传递给它。也可以说，依赖被注入到对象中。所以，控制反转是，关于一个对象如何获取他所依赖的对象的引用，这个责任的反转。
依赖注入(DependencyInjection)和控制反转(InversionofControl)是同一个概念。具体含义是:当某个角色(可能是一个Java实例，调用者)需要另一个角色(另一个Java实例，被调用者)的协助时，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在Spring里，创建被调用者的工作不再由调用者来完成，因此称为控制反转;创建被调用者实例的工作通常由Spring容器来完成，然后注入调用者，因此也称为依赖注入。
不管是依赖注入，还是控制反转，都说明Spring采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。在理解依赖注入之前，看如下这个问题在各种社会形态里如何解决:一个人(Java实例，调用者)需要一把斧子(Java实例，被调用者)。
(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:Java程序里的调用者自己创建被调用者。
(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。
(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。
第一种情况下，Java实例的调用者创建被调用的Java实例，必然要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合。
第二种情况下，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用。此时调用的代码面向接口编程，可以让调用者和被调用者解耦，这也是工厂模式大量使用的原因。但调用者需要自己定位工厂，调用者与特定工厂耦合在一起。
第三种情况下，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。事实上，调用者和被调用者都处于Spring的管理下，二者之间的依赖关系由Spring提供。
所谓依赖注入，是指程序运行过程中，如果需要调用另一个对象协助时，无须在代码中创建被调用者，而是依赖于外部的注入。Spring的依赖注入对调用者和被调用者几乎没有任何要求，完全支持对POJO之间依赖关系的管理。
依赖注入通常有两种:
1、设值注入。
2、构造注入。

Answer 2

1、分层，一般MVC框架开发，比如ssh，一般都会有service层与dao层，依赖注入可以提高层与层间，方法的重用，比如你在dao层写了一个方法，可以供service多个方法调用。
2、反射仅仅是实现了资源注入的功能，但是session控制、bean的生命周期等等等等，你不会都要自己开发吧，的确，单纯反射机制可以实现那些资源注入的功能，但Spring不仅仅是ioc与aop这两个哦。
反射机制，可能是你用到的全部，但是只是Spring的一部分而已

Answer 3

我发表一下我的看法.个人认为,大型框架在单纯的机制上跟反射没什么,只不过是,它整合的东西多.要做到协调性,还是需要大量研究的.所以,单纯的说机制,却是没什么高深的.如果说协调性,那不是一个人可以三天两早晨做的非常完美的.要协调资源.协调用户感受,协调处理数据关乎到其它软件的底层了.比如数据库之类的.这是我想说的.也许说的 不全,但我相信楼主明白偶滴意思.

Answer 4

有些东西，你没有做太得深，你没有做得足够多，说了你也体会不到，这种学术性问题真不想多说，真正的收获是实践中慢慢总结出来的。你可以想象一下和一个刚学JAVA的人说：你的代码要分层，看看他能听得进去吗

找个像样点的公司，好好工作一两年，你再回头来说服你自己，那就是真的进步了，如果你抱着一种我的观点就是对的这样的态度去看待前人的经验而不是去研究它的机制，那你只能是在绕远路。

追问

如果你说不出 那些大型框架 比我的 反射类 有点强多少倍，你是不可以直接说服我的！
我现在已经工作，而且对架构的领悟也不算差，自己也有自己的框架！

我只是不相信：我自己领悟的东西居然别人还要 用 “控制反转，依赖注入”这么高深的名字！！还要开发大型框架！

追答

你可以对比一下你的反射类和spring的注入使用，哪一种使用起来更方便。

控制反转，依赖注入，根本不是什么高深的名词，只不过是说把控制的主动权转移了，不由调用者决定要调谁来实现，而是由被注入决定谁去实现

依赖注入的确是个简单的技术，但是spring这些框架的强大，远不是因为它会依赖注入，你的反射，最终不还是创建出了实例吗？spring默认情况下获取一个bean是单例的，而不是new出实例给你。而且正是有了这种接口式的注入设计，才会有这么多开源技术可以通过spring简单整合运行，节省了大量的整合工作

再来个实例，某个类要使用第三方实现来处理快递流程，它注入了一个标准接口，里面有查运费，查收货地，查快递配送状态等标准方法。而实现类有多种，比如申通的实现，圆通的实现。
现在你可以用spring进行配置了，喜欢用哪家的就注入哪家的，还可以注入个工厂类来同时使用多家的。你反射怎么搞？从申通的实现换到圆通实现时，把你要反射的类名字全部改一遍吗？

Answer 5

这个符合面向对象的思想。打个比方
你需要锤子，你可以
1、自己去造。用java的话说就是调用者创建被调用者
2、你可以要找到生产锤子的工厂，向工厂购买即可。对应java的工厂模式。
3、你可以打电话找到卖锤子的商店，让人把锤子送货上门。对应spring的依赖注入

以上第1种办法，要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合
第2种办法，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用
第3种办法，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。调用者和被调用者通过spring管理。他们的关系由spring维护

你自己想想，如果拿到的锤子不是你想要的，哪个办法更方便