对依赖注入的一些理解

假设有两个 JavaBean，A和B，若A中调用了B，通常情况下是通过new创建一个B对象，但使用spring之后，可以将B作为A的一个属性，设置set方法，同时在spring配置文件中对B进行实例化。

这样做将B的实例化从具体的对象转移到了容器中。

以来注入的好处可以这样讲，若因为需求变更，A不需要使用B了，改用C了，若不使用依赖注入，则需要修改A程序并需要重新编译，而若使用依赖注入，在A编码时，将B抽象成一个接口，并将该接口作为A的一个属性进行使用，在具体的A程序实例化时，通过配置文件指定需要具体使用的bean即可。下面转载的文章更形象的说明了这种好处。http://tech.ddvip.com/2008-11/122794102996162.html

配置文件是struts核心的一部分，许多人都不喜欢使用配置文件，我也是其中一个。记得刚开始接触struts的时候，对它的配置文件实在是很烦，但慢慢地，了解了配置文件的作用之后，就喜欢上使用配置文件了。配置文件在项目中的作用是毋庸置疑的，在大型的项目中尤其重要。需求是不断地改变的，但我们的程序可不能老跟着需求变，即使老板吃得消，员工也吃不消啊。改变一个页面的业务逻辑，只需要在配置文件中修改一下action的配置就可以了，其它的代码都不需要改变。说到配置文件，它还有一个很重要的作用，那就是“控制反转”或者“依赖注入”，其实我也搞不清这两个词语之间是什么关系。不过，也没必要在这些文字间咬文嚼字，就用IOC来代替它们好了。在开发过程中，经验会遇到一个类里面包含另一个类的实例，如： class A { 　　……….. } class B { 　　A a = new A(); } 　　那么，在上面的代码中，B将依赖于A，也就是说，没有A，B就无法正常的执行。这样，B和A就产生了耦合。说得再明白一点，如果B的业务逻辑需要改变了，不想使用A，而是使用C，那么，就需要修改B的代码，还要重新编译，这对于大型的系统来说，需要起来代价是很大的。为了达到高内聚低耦合的需要，我们应该让B依赖于抽象而不是具体。比较常用的方法是使用工厂模式，如： interface IA { 　　…… } class A { 　　……….. } class B { 　　IA a = Factory.CreateA(); } 　　那么需要改变时，只需要发动工厂就行了，这大概就是平时所说的控制反转吧，由以前的修改B类转为修改工厂类。但是还是需要修改代码，当需要扩展新的类时也要修改工厂类，这明显是换汤不换药嘛，依赖注入也就应运而生了。 　　对于依赖注入，我的感觉是就像是打针，需要什么就往里面注射什么。那么针在哪里？当然是在配置文件里了。要实现依赖注入，得修改一下B类，添加Setter方法。 class B { 　　IA a = null; 　　IA A 　　{ 　　　　set { a = value; } 　　} } 　　此时，B类中A属性就可以通过配置文件来注入了，想要A就注入A，想要C就注入C，多方便啊。注入，你可以这样理解：类是一个封装体，就把它想象成一个空心的球体吧，Setter方法相当于这个球体的一个小孔，注入也就是把它需要的东西通过这个小孔往里面塞。 　　说了这么多，其实都是在为我下一篇的文章作准备。下一篇文章将发布nstruts2.0，它比先前发布的nstruts1.0有了很大的改进，增加了许多新的元素，并且还支持依赖注入，注入的数据可以是对象，常量，还有集合。这些功能已经能完全满足项目开发中大部分的需求了。同时，nstruts2.0将会是个很好的学习实例，它设计的思路比较清晰和简单，对象框架设计感兴趣的朋友都会有或多或少的帮助。在发布之前，大家可以先看下我先前发布的nstruts1.0，了解一下大概。