阿Q:革命了，革命了！（也谈IOC的好处）

国内热炒了spring等IOC很久了，竟然没几个人能说清楚IOC的好处，真是浮躁的可以啊，Q前辈的影响还是不小啊。

这个问题havenmind的文档上讲得很清楚.

Why should you use HiveMind?
The concept behind HiveMind, and most other dependency-injection microkernels, is to reduce the amount of code in your application and at the same time, make your application more testable. If your applications are like my applications, there is an awful lot of code in place that deals just with creating objects and hooking them together, and reading and processing configuration files.

HiveMind moves virtually all of that logic into the framework, driven by the module deployment descriptors. Inside the descriptor, you describe your services, your configuration data, and how everything is hooked together within and between modules.

HiveMind can do all the grunt work for you; using HiveMind makes it so that the easiest approach is also the correct approach.

如果我没有理解错的话，IOC的主要目的是减少重复的代码装配的代码，让框架代劳。

IoC 主要作用是体现在设计一些framework上面...你所说的装配只是在分离了接口和实现后，IoC容器的一项基本功能罢了...

这个是我个人对IoC的理解...

到底是havenmind还是HiveMind

我觉得使用IOC的好处不仅在于方便了接口分离等概念，更多的是一种强制措施，就是强制你写出层次清晰的代码来，改变原有的代码习惯，使之更适合TDD和敏捷方法。

昨天跟CSDN的技术人员讲了一下IoC和Spring容器（现在也有.NET版的），他们很快就理解了。其实道理很简单：假如A需要用到B，假如由A自己创建B，那么A就跟B绑在一起。以前他们解决这个问题的办法就是type 0 IoC，需要用B的时候从参数传进去。现在有了容器，他们马上就明白该怎么用。所以对IoC、对Spring的误解，我看还是自己的OO程序都写得一塌糊涂，压根就没想过A和B原来还需要解耦。

really ,自由是要付出代价的!
让我们回头来看看这个故事

如果只有两个人的交互A不创建B谁来创建?


对阿A和B是需要解耦!怎么办必须在引入一个C做导师,告诉A :你翅膀还没硬呢!要找B类型的mm?有了类型(interface)我帮你拉一个过来!于是故事变成这样的:


于是两人世界变成了三角关系：A-->C;C-->B （--〉为依赖关系）真的变简单了么？A丧失了B的决定权的同时，还得去求C，最后得到的还不一定正确！C always right？

在来个复杂点的故事

现在要球A和B解耦 ：怎么办呢

你是C你会说什么：
靠，我都搞定了要你干啥?

class A {
  public A(B b); {

请问A怎么会依赖C？

// 这就是你所说的C
class Container {
  public Object getObject(String name);;

请问C怎么会依赖B？

你脑子里想的，还是把容器当工厂来用。说过一百遍了，容器不是这样用的。

// Dependent Component
public interface BIntf {
  void doSomething();;
}
public class BImpl implements BIntf {
  public void doSomething(); {
    // do something here.
  }
}

// Component A using B
// 1. without IoC, direct create
public class A {
  public void doSomething(); {
    BIntf b;  // dependency #1, with BIntf
    b = new BImpl();;  // dependency #2, with BImpl
    b.doSomething();;
  }
}

// 2. without IoC, using customized factory
public class A {
  public void doSomething(); {
    BIntf b;  // dependency #1, with BIntf
    b = BFactory.create();;  // dependency #2, with BFactory
    b.doSomething();;
  }
}

// 3. type 0 IoC
public class A {
  public void doSomething(BIntf b); { // dependency #1, with BIntf
    b.doSomething();;
  }
}

// 4. type 2 IoC, setter injection
public class A {
  private BIntf _b;  // dependency #1, with BIntf 
  public void setB(BIntf b); {
    _b = b;
  }
  public void doSomething(); {
    _b.doSomething();;
  }
}

// 5. type 3 IoC, constructor injection
public class A {
  private BIntf _b;  // dependency #1, with BIntf 
  public A(BIntf b); {
    _b = b;
  }
  public void doSomething(); {
    _b.doSomething();;
  }
}

哪个依赖多，哪个依赖少，一目了然。

C 说 A 你我去桂林，你帮我安排一下吧！A 说没问题， ：对了旅馆代理 你注射给我，我车票代理 你注射给我， 我还需要导游你介绍给我，都全了？我开始给你安排


关键的问题是,如果你认为这家旅馆或车票代理永远不会倒闭的话,你可以这样做....如果一个月后倒闭了...后果

稍微改动一下

你项目中的A到底是什么?