个人观点，有理解不到位或者错误的地方，请不吝赐教。
Interface bi;
Class b implements bi;
1. Class a 中，Class bi = new b();
a 和 bi是编译时耦合。
a 和 b 之间是编译时耦合。
2. Class a 中，Class bi = Class.forName("b").newInstance();
a 和 b 是运行时耦合，但是只是推迟了耦合的时机，和 1 没有本质区别。
3. Class a 中，Class bi = Class.forName(bname).newInstance();
bname从外部配置文件中或者参数中获取。
a 和 b 是潜在运行时耦合，你可以用类c替换b而不会影响a。
IoC的效果和 3 一样。
对于耦合关系的设计并不是越低越好，也不是越高越好，而是必须将设计中的耦合关系和业务模型中的耦合关系保持一致。
当业务模型中a必须依赖b的时候，最好的设计是1，这个时候代码最清楚、简洁，也最直接的表达出它们之间的耦合关系，如果用3反而使得a无法理解。
当业务模型中a是依赖于bi的某一种实现的时候，最好的设计是3。
注意，在设计过程中，解耦不是目的，让bi的实现可以不影响a而变化（前提是bi的实现确实存在潜在的变化可能）是目的。
使用IoC也一样，不要把所有的依赖关系的分离，这样你的设计将让人无法理解，包括你自己。
>在例1中用new c（） 代替 new b（）不也是可以的吗，假设c和b都实现了bi接口。
如果你愿意修改代码的话，一切都是可能的。
是的，完全正确。你不可能消除依赖（对接口、对类），但是你可以用不同的方式来实现依赖。如果a在运行的时候要依赖b的时候，一定在某个地方你可以看到这个依赖关系，只是这个关系的表现各不相同而已。
是的，你当然应该关心业务逻辑之间的耦合关系。但是关键在于你不要将不应该耦合的对象耦合在一起，也不应该将该耦合的对象分开，同时你还要考虑在可以预料到的将来，耦合关系会如何变化。
对象之间的依赖关系是面向对象设计过程中非常重要的内容（OO设计主要两件事情，一是如何设计对象，二是如何设计对象之间的关系）。
那是因为依赖关系变成容器中的Autowiring了。无论任何情况，你还是必须知道Autowiring的基本原则，其实说到底就是将其他的依赖关系（语言的或者配置的或者其它）转换成约定的依赖关系（Autowiring规则）而已。
banq老大说的应该是“约定优于配置”的意思吧，我对之前对这个概念没有多少了解，字面上看，应该是说将之前需要配置的一些部分换成大家的约定，从而减少多余的配置文件，在网上查了下，也大概是这个意思，如果是这样的话，那它也只是对配置的形式做了改变，并没有实质性的不同。