还是没有明白IoC的好处

从头做当然不简单了，我是说用Spring的话。
若系统中有大量工厂和各类工厂组合使用时，用XML文件来配置应该会好维护一些。

如果使用现成的框架的确可以把事情简化到使用xml进行配置。不过对已有的代码需要进行修改吧，我对spring不太熟悉，不知道它是否可以给已有的工厂类增加新的注射的创建方法。至少aspectJ是可以这样做的。

IoC强调的是面向接口的编程，强调的是轻量级容器，能够使编程、测试变得更简单，在一定程度上能够提高开发的效率。

想想我们对EJB做单体测试是一件多么痛苦的事情啊。

我想问题的关键问题在于解耦,至于什么方式无所谓了,我想我比较喜欢2(setter),3(interface).用XML属于数据驱动的方式来隔离变化.也是很不错的.

一般的，是不用把Factory传递进来的。
但是有种情况，我认为还是需要传递一个Factory或者ServiceLocator

例如：

public class A{

  public A(B b, C c, D d, E e, F f, G g);;

}

由于构造函数参数过多，调用的人会很困惑
当然，用pico不用管这个，不过我们测试的时候哪？

因此，我考虑用这样一种方式来替代

public class ServiceLocatorImpl implements ServiceLocator {
  public  ServiceLocatorImpl(PicoContainer c);;
  public getB(); {
    return (B); pico.get(B.class);;
  }
}

就是将bcdef的取得过程合成一个ServiceLocator

public class A{
  public A(ServiceLocator sl); {
   this.b = sl.getB();;
   ...
  }
}

按照pico本意不应该这样吧，如果你依赖很多其他组件，他们又是毫不相关的，那么这个类就设计得不好了，太多依赖，太多的变化，职责可能太多，要重构了。如果是相关的，一般也可以合并一些东西了，也许用个factory也不错，但是不应该把容器嵌进来吧，很大程度上破坏了IoC的好处了，而且看上去也有点不舒服，因为某些组件中间突然出了服务定位器，如果是不同层之间的依赖可能还好有点，不过如果不能直接IoC继承不如直接在pico上面封装一层接口得了？

有一个问题不解:
如果是在同层之间,有二个类A和B,B需要在它的某些方法里动态创建A
比如这样子:

 
A B.newA(); {
    return (新建一个A);;
}

而A必须注入一些别的类,那在B里面如何创建A啊,总不能得到B所在
的容器再从容器get吧,因为注入只有从容器get才会发生啊.

其实IOC是一个很好的概念.
可惜正真用起来的时候,不支持编译前检查,当然这也不能说是IOC的错误,这只是实现者的错误.
如果能把类似这种 Bean bean=(Bean)xxxx.getBean(id); 改成直接 Bean bean=new Bean();new时进行IOC操作(上面是用了spring的代码说明).

希望早日来到.

:oops: 在spring中你如果要一个a可以通过context从容器中抓一个出来，也就不会有要不要设定get方法等等的问题了

个人感觉如果配置文件太多头疼，一个struts有时配置文件出错了，我都要调试半个小时才找到原因，也许是我太笨了吧^_^