IoC/DI在项目中的实际运用？

简单地说来IoC的目的也就是让接口跟实现分离，这也是OO倡导的面向接口编程。

但是实际的使用中是否有必要？你的接口是否稳定？有为一个接口提供多个实现的必要性？

什么情况下没有必要使用IoC？不稳定的接口是设计上的问题？为什么不在重构的时候在考虑用IoC，而不是一开始就使用，感觉最近IoC的运用跟设计模式一样有些过度了，不知道大家有什么看法，能不用就不用？

[quote="ThisWorld"]简单地说来IoC的目的也就是让接口跟实现分离，这也是OO倡导的面向接口编程。 但是实际的使用中是否有必要？你的接口是否稳定？有为一个接口提供多个实现的必要性？ 什么情况下没有必要使用IoC？不稳定的接口是设计上的问题？为什么不在重构的时候在考虑用IoC，而不是一开始就使用，感觉最近IoC的运用跟设计模式一样有些过度了，不知道大家有什么看法，能不用就不用？[/quote]

个人认为使用Ioc倡导的是接口跟实现分离，避免硬编码，促使一种良好的编程习惯，并且使用起来很自然，避免了你自己使用Factory,Singleton什么的了，没有过渡设计的味道吧。。。

就为了OO倡导的接口跟实现分离就用IoC？不稳定的接口怎么解决？为什么不等到重构的时候再用？

[quote="ThisWorld"]就为了OO倡导的接口跟实现分离就用IoC？不稳定的接口怎么解决？为什么不等到重构的时候再用？[/quote]
接口基本上应该是稳定的，当然随着对需求的进一步理解，可能开始抽象的不够，引起接口的变动。不过这种情况下，一般只是
在接口中添加内容，对其他部分影响不大。如果是在需要合并接口或其他的方式引起的接口变动，这样可能影响的范围会很大，所以开始就应该仔细设计接口。
但如果不使用IoC,接口和实现分离也是应该倡导的一个好的编程方式，如果你开始所有的都是基于类编程的，等你对需求了解深入了，项目完成大半了，再试图重构出接口，困难会非常大（本来能重构的一个等级的，而这些方法的命名因为不一致而使重构变得困难甚至不可能），除非你在设计每个类的时候就考虑，将来要和某某类抽象出接口（如果你是遇到能抽象出接口的几个类就重构出接口，那么将和开始就使用接口类似，产生不稳定的接口，甚至更糟，你看的可能太局部了，而开始就仔细设计接口，许多时候会设计出高质量的接口）。
其实接口作为一种协议、规范，大家在写代码的时候就会遵循这个规范去写实现类，如果开始没有了这个规范，就会乱做一团。
所以我感觉关键是在开始就要仔细的设计接口。

同意楼主观点——需要的时候再重构出接口，这也是一种pragmatic的做事风格。
DI只是让“面向接口编程”这项最佳实践变得更容易、成本更低。

根据我使用spring的经验，应该使用接口，或者说能从接口得到好处的地方大概有这么几个：
1、Service层组件需要发布成远程对象（如EJB/RMI/webservice/Hession）的,
   使用接口可以对调用者隐藏分布式实现的细节
2、Service层组件需要配置AOP事务代理的，如果没有接口，
   Spring底层会用cglib实现AOP代理，性能稍差一点点
3、访问外部资源的组件，为了便于mock单元测试，需要它有个接口