还是没有明白IoC的好处

特别支持一下这句，凡事做过头了就不好了

我印象中最失败的就是DAOFactory。通过Factory取DAO实例，比直接new一个DAO到底好在什么地方？结果系统上线后DAO就从来没有换过，倒是里面方法的逻辑经常修改，这样的工厂有用吗？类似的，一个IoC类这种灵活性到底给我们带来多大的好处？我经历的东西太少，能否哪位有实际的不用ioc就不爽的例子？

好处还是有的,在你初始化的时候能够多做一些事情.修改的时候只修改一个地方。

这种想法也是滥的不能再滥，还记得组件式编程吧，人们总是喜欢幻想写软件就象玩积木或装配机器一样简单，只要把恰当的东西拼凑起来就可以了。这种幻想泡沫冒出来也不是一天两天了，最后我们还是发现如何编写万用的组件比如何把组件装配起来困难一万倍。所以IOC无非就是华丽的泡沫，干干配置工作还是可以的。

不止是记得，现在正在回过头去重新研究。随着技术的进步，经验的积累，我现在觉得这已经不是幻想了。

有个实用的地方，开发的时候Mock对象。
在mis应用中，几乎找不到IOC表演的一个例子。
其它框架什么的，是IOC发挥的一个好地方。
IOC是可以玩，但是玩得好不好，取决于设计的对象是否与应用的业务情况刚好有较好的。。从这个角度来说，IOC不是关心的问题，一切技术都是废的，而是看对业务的熟悉程度！

Class A{
  B b;
  A(A b);{
    this.b = b;
  }
}

这就是ioc了。所谓ioc，不过是你需要一个东西，让外面不管什么人给你传递进来，你自己不去主动寻找这个对象。
你说这叫decorator? proxy? bridge? 还是什么都不是？


这句话是错的。是”全部交给别人负责“。
至于是谁负责，不是你需要关心的。

所以java.io的decorator当然是ioc。BufferedReader根本不关心谁给它一个Reader的instance，它只伸手要，却不管从哪里得到。
所谓模式模式，千万别陷入唯名的陷阱。很多时候，一个设计方案从不同的角度看，就可以叫做不同的模式。
所以，忘了什么”模式“吧。

那是因为早期的mis比较原始，不考虑什么重用和定制，今年我的两个mis全部基于ioc，从两个项目的开发中，真正体会到ioc的好处，也经历了上面所说的，处处getObject到不用getobject的变化。

btw : 我用的ioc是自己用     vb6 实现的,仿spring.net context的实现,在vb6这种不特别oo的环境中，ioc会强迫你用oo去思考。如果你体会不到好处，再争论也是没有用的，因为从我的实践过程中，接受ioc相当是一场洗脑，在1个星期左右时间内，都相当困扰

"一个设计方案从不同的角度看，就可以叫做不同的模式" 这个我赞同, 但是java.io的封装目的是为了向外界提供更多功能的接口, 比如FilterInputStream, FilterOutputStream等, 而不在于如何使用被封装的IO对象. 这一点和我们大多数遇到的IoC应该是不同的. 应用IoC的地方, 大多是获取一个封装了一定业务逻辑的对象, 完成其他的逻辑. 出发点都不同, 只是java.io在代码上似乎符合某些type的IoC, 怎么能混为一谈呢?

即使这样, 某些framework中的IoC到底有啥优势?

实际上是你强迫自己去套ioc的概念，如果你把ioc换成factory，从factory的角度上去考虑系统设计，自然又会有另一番感悟。