依赖注入或者称反转Ioc，通过第三方框架将你需要依赖的类主动注入进来，依赖注入随着Spring和JavaEE6普及，已经成为大家习惯的一种默认处理类关系的方法。
我将依赖注入和事件编程进行联系比较，是源于某天我突然发现，这两者实际是处理依赖关系的不同方式而已。打个比喻，某个工厂缺少某个部件，通过采购快递将部件送到厂里，这是依赖注射；而有的工厂则相反，委托别的工厂生产好部件后，不拉进自己厂里，而是将自己产品拉出去和那个部件进行组装。
是不是有些绕人，以代码来说明：
public class A{
B b;
public void a1(){
b.xxx();
}
public A(B b){
this.b = b;
}
}
public class B{
public void xxx(){
System.println("hello");
}
}
|
A的方法a1()中需要依赖B的xxx()方法，我们就用Ioc框架将B实例通过A的构造器或者Setter方法注入，注意，其实我们没有发现这里有一个很严重的设计问题，依赖是方法行为的依赖，因为方法有依赖，造成两个整类发生依赖，是不是有点影响面扩大呢？
如果说，通过构造器注入可以保证这两个类的对象生命周期一致，那么通过setter方法进行注入，更容易产生两个类的对象生命周期不一致。而我们很多人适应了Spring的setter方法注入，竟然熟视无睹如此丑陋危险的做法，这也是构造器注入要强于setter方法注入的地方(jdonframework只提供构造器注入的原因)，当然，这也只是50步笑百步，从根本上讲，我们不能因为两个类的方法有依赖，就将整个类发生关系，这实际是一种结构偏执思维。
那么如何解决这个问题？从行为模式入手，通过事件模型来解决这个问题。
我们知道事件模型类似观察者模式，有事件的产生者和事件的处理者两个角色，这两个角色通过事件产生了一种联系，实际就是一种依赖。
我们用Guava的事件编程改造上述案例：
事件模型的代码和依赖注入代码的区别是：原来A直接依赖B，现在我们更改为A依赖事件总线对象，注意，这个事件总线其实类似Ioc容器是全局的。换句话说，A对B的直接依赖加入了第三者：
原来:
A --> B
A ----> 第三方 ----> B
这种处理松耦合的方式非常类似我们引入接口，也非常类似facade模式 代理模式等等。
更重要的是，我们避免了因为A的一个方法对B的依赖，而将整个B注入的粗糙做法，泼水泼掉孩子的傻事情不能再做了。
从以上看出，事件编程是对传统依赖注入模式的补充，它们的主要区别是依赖方向的不同： 依赖注入是有点facade模式，大包大揽，以自我为中心，其他人都要来配合我，都注入到我的边界内部，最后我的边界内混乱不堪不说，又会制造新的紧耦合。 事件编程的则从我内部发出事件即可，不要把污七八糟什么人都领到家里，做什么事情完全可以到外面去实施，在家里打个电话指示一下就可以。
