还是没有明白IoC的好处

看到的范例中所使用injection的方法将一个对象的instance注入Factory类中，其实这样的Factory有何用？

感覺上去如果程序寫多了就自然而然會明白IoC的好處,就象對模式的理解是一樣的,不在於你理論看的多,而在於實踐代碼的多少.
我和樓主一樣,不是很明白它的好處.
比如說它會帶來更多可重用的類,我明白,引入了中間類,當然會帶來這個效果,可是肯定也會帶來一些麻煩.如果一個系統足夠複雜.類足夠多,你還要去引入很多的中間類.這一步能不能在重構的時候做.那樣可能會好一點.
關注中

假如A组件需要使用一个符合I接口的组件.
只要改改配置文件文件就可以换个符合I 接口的组件给A用,不用在A组件里改代码了.

可以不更改和重新编译client的代码，优化、扩展server的功能，替换server的实现

假如A组件需要使用B组件，假如我们用工厂（或者service locator），那么A组件就需要写：
B _b = serviceLocator.getBService();

那么如果你要把A组件拿到另一个系统里面用，你就必须修改它的源码，让它使用另一个系统的serviceLocator。换句话说，你这个组件不具备可移植性。这就是需要依赖注入的道理。



这不是需要IoC的道理。你可以想象一下，如果你的service locator把“创建哪个具体类”的信息配置在XML文件里，情况会怎样？

诸位在这里所宣称的IoC的好处，似乎也只是面对接口编程的优点。或许这么说，IoC所说的注入，意图是能够让我们的软件更为组件化？ 可我的疑问是，看到的范例中所使用injection的方法将一个对象的instance注入Factory类中，其实这样的Factory有何用？我总认为Factory应该起一个封装的作用的

如果用IoC自然就不会再用serviceLocator了,否则就不叫IoC 了
我只是在A组件里声明一个接口,举个简单的例子
class A{
   private IB b;
   public void setIB(IB b){ //声明需要符合IB接口的组件来提供服务
       this.b=b;
   }
 
   public void doSomeThing(){
       xxxxxx
       b.help();
       xxxxx
   }
}
当容器在实例化A的时候，会按照配置文件找到A需要的组件b传给它来用。这样，只要改改配置文件，就可以让容器给A提供不同的IB实现了。
另一方面，由于IoC组件框架的各家实现也还处在“乱斗”状态，没有一个规范可以遵循，所以本来就不存在可移植性。 我为avalon写的组件无法拿到spring下面跑，spring下面的组件也无法拿到PicoContainer下面去跑。这是另一个话题了

Ioc实现的功能用接口、工厂也是可以实现的啊，我也没明白它的好处，只是感觉用XML配置方式会使得事情变得简单一点。

我觉得用了xml也没变简单，你要写xml的解析程序需要些框架的程序，你要让写client的人知道怎么使用xml进行配置。这些事情难道很简单吗？