依赖注入与事件编程(设计模式)

作者:xinwang_m@163.com
发布时间: 2020-07-17 11:49:58 (4年前)
关键词: 依赖注入与事件编程
摘要:

                              
                                     依赖注入或者称反转Ioc，通过第三方框架将你需要依赖的类主动注入进来，依赖注入随着Spring和JavaEE6普及，已经成为大家习惯的一种默认处理类关系的方法。

依赖注入或者称反转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的事件编程改造上述案例：
public class A{ EventBus bus;
public void a1(){ bus.post(“xxx”); }
public A(EventBus bus){ this.bus = bus; } }
public class B{
@ subscribe public void xxx(){ System.println(“hello”); } }
EventBus bus = new EventBus(); bus.register(b);
事件模型的代码和依赖注入代码的区别是：原来A直接依赖B，现在我们更改为A依赖事件总线对象，注意，这个事件总线其实类似Ioc容器是全局的。换句话说，A对B的直接依赖加入了第三者：
原来:
A —> B
A ——> 第三方 ——> B
这种处理松耦合的方式非常类似我们引入接口，也非常类似facade模式 代理模式等等。
更重要的是，我们避免了因为A的一个方法对B的依赖，而将整个B注入的粗糙做法，泼水泼掉孩子的傻事情不能再做了。
从以上看出，事件编程是对传统依赖注入模式的补充，它们的主要区别是依赖方向的不同：
依赖注入是有点facade模式，大包大揽，以自我为中心，其他人都要来配合我，都注入到我的边界内部，最后我的边界内混乱不堪不说，又会制造新的紧耦合。
事件编程的则从我内部发出事件即可，不要把污七八糟什么人都领到家里，做什么事情完全可以到外面去实施，在家里打个电话指示一下就可以。
本文主要通过实践说明处理依赖关系的两种不同角度，特别是我们进行面向对象编程时，要有很强烈的对象生命周期概念，当我们绑定两个对象时，就如同绑定两个人，这两个人有各自自己的生命轨迹，他们可以在一起共同生活多长时间？如果这些Scope时间边界问题不考虑，那么还不如全部使用静态全局变量编程，避免徒增烦恼。

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论