还是没有明白IoC的好处

同意！ioc的解耦，不过是多构造函数的解耦！所谓的容易测试，mock 等等，都是由这一个好处带来的。号称没有侵入性？ 怎么可能？你怎么拿到呢个接口的实现的？ 不用new ？总要用到一个类吧，用spring？你的代码里面就不得不依赖它了！说到底就是用一个配置文件来保存类的名字，外加一个时髦的xml。其实依赖本身没有改变，只是依赖关系不断的向上移动，移动到xml文件里面！到时候要修改xml文件，不修改java文件而已，其他没有什么新的变化！
  修改xml不用编译？代价是，依赖关系没有人来检查，类型关系没有人来检查！值得么？

如果你能做到不用getBean ，就能体会到ioc的好处。
讲讲我的三个阶段
①到处用getBean

②用servicelocator模式，只在一个类中用getBean
③不用 getBean

spring IDE 多少能帮点忙

我认为ioc有它的好处，但是现在的流行，造成了他的使用过度：我认为应该是在compent 级别使用，而不是在每个class级别，力度控制的不好。有什么应用时成天换掉一两个class的？一般都是组件的替换。反对者可能认为单元测试的时候ioc作为工厂有很大的优势，mock比较容易！但修改配置同样是危险的，危险成对可能比修改代码的危险程度根大，没有必要的检查

怎么会没人检查？就算你从来不写单元测试，冒烟测试总要做的吧大哥？

赫赫，大哥实在不敢当，我可是天天看您老的blog学习呢！
问题时：把工厂全交给xml是否换算：
1）接触耦合？放在java的工厂里面和xml没什么不一样吧
2）检查？当你修改过java文件后，编译器自动帮你检查，不需要人工的测试来检查 是否划算一点？安全系数更加有保证？
3）我承认修改xml似乎更加有灵活性，（对于客户而言）但是我还是要说这里有一个粒度问题，粒度大一点 按compent来可能更好一点。给客户一定的选择余地！但是每个class都是可替换的，似乎很容易出错。

初看确实觉得很有意思。后来看多了，感觉就是原来有变化要改java代码，现在是改一堆的xml；原来是对java编程，现在是对xml编程。只是说不需要编译了。可是一个系统上线后，类的更换远没有类的修改频繁，甚至很少更改。那么为何将几百年都不会变的东西放到xml里？同样是面向接口编程，为何一定要IoC？

做个比喻：

假如有张设计图，还有一堆零件，那么可以随意根据设计图选择适合的零件组装。

IOC就有如这种工作方式,对象就象一张设计图。

ioc是ioc，配置文件是配置文件。
ioc是一个良好的设计理念，有什么过度不过度的？要我说，对ioc的推广还差很多。
很多人都是只知道个名词，然后把使用spring, pico的ioc容器和api作为ioc的标志。殊不知那样作确是适得其反。

容器和xml配置只是组装ioc对象的一个可选方式。同样也可以用java代码，脚本等来组装。某些子模块ioc了，但是使用者模块如果确切知道自己不需要这个灵活性，直接new一个对象传递进去也很好。
比如java.io的很多类都是ioc啦，但是没见谁在xml配置文件里去配置InputSteam， Reader之类的。

当然，我强烈同意配置文件里面只放粗粒度的组件。

java.io包里面的类都是IoC？咋讲？不太明白，java.io里面连接口都没有，用的是众所周知的装饰模式，能否给具体解释一下？那是不是使用装饰模式的都可以称为IoC了？

我理解的IOC就是连工厂都不要了，全都交给容器负责，容器当然要从xml中找到具体的配置。如果说这种配置硬编码到代码中也可以，或者用一般java代码或者脚本，但是和容器起同样的作用。还不是一回事？如何把IoC和容器分开理解的，还请高人赐教？