Spring新手对依赖注入的理解

今天学了一下Spring的依赖注入，也称作是“反转控制”。
   当一个类A需要用到另一个类B的对象的时候，通常情况下，就是在A中实例化一个B类的对象，然后通过对象来调用B类中的非私有变量和方法。这是不符合工厂设计模式的要求的，并且这样的设计方式存在很多的缺陷：
  其一，A类去主动调用B类的构造方法，这就使得A类和B类之间的关系非常紧密，在Java程序设计的过程中，这种两个类之间关系非常紧密的情况是非常忌讳发生的，因为结合紧密的两个类在程序设计过程中会很难进行调试，尤其是在大的程序中，如果一连串的类之间发生调用关系，那么如果其中某一个类发生了改变，或者说某一个或者几个类发生了错误，需要调试，那么，所有调用到这几个类的类都要进行相应的修改，这是很麻烦的事情。
   其二，A类调用B类的方法，这就说明，A类必须知道B类方法的实现方式，这样使得AB之间的耦合度相当高，这也是不利于Java程序设计的。整个java程序设计的发展历史，就是一个怎样在类与类之间解耦的过程，让有关联的类处于一个松耦合的状态，这是java编程所追求的一个目标。
  Spring框架是工厂设计模式的一个非常好的体现，也同样特别注意了“解耦”，同样，它也是用接口的方式将程序解耦发挥到一个新的境界的框架。
   同样引用上面的例子，类A需要用类B的方法，在Spring框架中，不再是由A去主动调用B的构造方法，而是由Spring容器来完成，Spring容器只需要知道A需要得到哪个Bean的实例，就会帮A去创建一个B的实例，并不需要A自己去调用B的构造方法，Spring怎么知道A需要哪个Bean的实例？这就要涉及到Spring的IoC容器，它是一个“工厂”，可以对每个Bean以配置文件的形式进行管理，而A需要B对象的时候，就只要创建一个工厂实例，然后通过工厂实例来获得一个B的bean实例，这样就可以去使用类B的非私有成员了。
  从整体上看，所有的类并没有和于它关联的类有任何的直接联系，所有的类都通过配置文件的形式，“挂”到Spring容器里去了，由Spring容器统一管理。调用者直接等待容器把被调用者的实例“注入”进来，然后使用。由此可以想象，Spring容器的功能应该有多强大。