对于最近一篇帖子"解释一下，为什么需要接口而不直接实现类"的讨论引申出对spring的思考...

本人以前对spring用的甚少，基本都是搞EJB或者Seam.用spring只是在一个C/S程序中来配置一些简单类(确实比我手工创建爽多了)，一直不明白spring提倡的IOC或者说DI究竟有什么好处，通过上篇帖子的辩论，重新思考了这个问题，同时感谢
深秋小雨童鞋提供的帖子[url]http://www.iteye.com/topic/3067[/url]。配合[url]http://www.zhuoda.org/xiaoming/66303.html[/url]可能会更清晰的了解这个概念。
大致上我算是了解了spring的优势。废话不说上代码：
假设我最上层的方法(假设就是一个桌面应用的Panel.OnButton_click(Object sender,Event evt)事件触发的方法)需要调用一个Service，现在先不管到底该不该有接口，我假设都是用接口，毕竟这是四巨头说的，这里有一个接口IService.

public interface IService{
    public void doSomething();
}

现在是IService具体的实现类,他需要依赖两个接口：InterfaceA InterfaceB

public class ConcreteService implements IService{
    private InterfaceA ia;
    private InterfaceB ib;

    public void setA(InterfaceA a){...}
    public InterfaceA getA(){...}
    public void setB(InterfaceB b){...}
    public InterfaceB getB(){...}
}

然后是具体的类ConcreteA implements IInterfaceA,ConcreteB implements IInterfaceB
配置一下Spring让它自动注入我直接可以在Panel.OnButton_click()方法中写调用beanFactory.getBean("ServiceA"),这样我就得到了ConcreteService类，不用写任何工厂。

到这里，似乎spring更本没有带来什么好处，毕竟，我直接写一个工厂。ServiceFactory,FactoryA,FactoryB,再在ServiceFactory的工厂方法里面调用FactoryA,FactoryB创建ConcreteA和ConcreteB对象。似乎也不用费什么力气。
如果不用spring,已经产生了3个工厂类了。

接下来，把应用复杂一点:ConcreteA依赖于另外两个接口InterfaceC InterfaceD

public class ConcreteA{
    private InterfaceC  ic;
    private InterfaceD  id;

    public void setC(InterfaceC c){...}
    public InterfaceC getC(){...}
    public void setD(InterfaceD d){...}
    public InterfaceD getD(){...}

}

同样，我只需要在spring中配置一下属性就可以得到IService的具体实现，并且让ConcreteService依赖InterfaceA,同时使ConcreteA依赖于InterfaceC和InterfaceD。

现在，假设我不使用spring,ConcreteA怎么设置依赖关系？我可能必然再写两个工厂：FactoryC和FactoryD
同时在FactoryA的工厂方法里调用FactoryC和FactoryD创建对象再将它注入到ConcreteA实例中。
现在工厂又多了两个，想像一下，如果依赖关系很多的话，将会创建多少个工厂，然后某个工厂的方法又调用另外的工厂的方法，到处依赖，难以管理。
就我这个破例子已经有5个工厂类了，很难想象大型的程序有多少个工厂类，这么多工厂类如何管理？

如果使用spring,则完全消除了工厂类，我不需要写任何一个工厂类。代码干干净净，我的业务逻辑可以轻松的放到任何一个其他的应用中，只需要合适的配置就行了，不依赖于任何一个工厂
似乎这就是spring的好处。
(注意：以上讨论都是建立在对接口编程的基础上)
在"为什么需要接口而不是实现类中"，robin说我对spring的使用连门都没有入，现在请问大家这个理解算不算入门了？