做过DOS编程的人都知道,Dos编程和Window编程最大不同之一就是事件机制的编程,普遍的,目前事件机制的使用已经在Windows下的应用程序中遍地开花了,可是基于事件传播的应用仅仅限于window应用程序吗?答案是:不。
在IOC概念的不断冲击下,我们需要回头去审视前两年自己开发的,心中为之骄傲的,认为非常优秀的程序,在这过程中,我们就会看到这些骄傲在最新的概念冲击下烟消云散了。变成了丑陋的,紧耦合的反面范例。让我们来看看以下场景:
某公司有基于某平台的两子系统,订购系统A和财务系统B。当采购员在预采购某物品前,先在定购系统A中登记需要购买的货物和价格,然后财务系统B就开始该笔购物款项的申请流程。
首先让我们来看看两年前的代码是怎么实现的:
private FinancialService financialService=new FinancialServiceImpl();
public Order saveOrder(Order order){
。。。。处理订单
financialService.createRequestOfMoney(order.getAmount());
}
}
从上面的代码中可以很明显看到,定购系统A和财务子系统发生了耦合,也许有同志说,那我采用Spring等IOC框架来解耦:
private FinancialService financialService;
public void setFinancialService(FinancialService fs){
this.financialService=fs;
}
public Order saveOrder(Order order){
。。。。处理订单
financialService.createRequestOfMoney(order.getAmount());
}
}
财务子系统B的实现FinancialServiceImpl是通过Spring等IOC框架设置进去的。这样不是很完美了吗?
但是我仍然要说,这个只是五十步笑百步罢了。再请看以下场景:该公司的业务规则起了变化,金额少于1万元的定购不需要通过财务申请流程。这样财务子系统B升级到B2了,多了一个直接拨款的API payMoney()。这时候,定购系统该怎么办?除了修改代码没有别的办法。这个时候,基于事件分发处理的机制就大派用场了。
修改原来的订单系统实现下单消息的广播。
private FinancialService financialService=new FinancialServiceImpl();
public Order saveOrder(Order order){
。。。。处理订单
brocastEvent(new Event(order)); // ***
}
}
实现一个消息监听器:
public void performed(Event e){
Order order =(Order) e.getObject();
financialService.createRequestOfMoney(order.getAmount());
}
}
在配置中设置(这里我们使用的是Spring)
<bean id="orderService" ...>
<property name="eventListener">
<list>
<ref local="orderListener"/>
</list>
</property>
</bean>
<bean id="orderListener" ...>
这样我们就实现了订单系统和财务系统的解耦,如果财务系统发生的修改,我们就只需实现新的监听器就可以了:
private FinancialService financialService;
public void setFinancialService(FinancialService fs){
this.financialService=fs;
}
public void performed(Event e){
Order order =(Order) e.getObject();
financialService.payMoney(order.getAmount());
}
}
下一篇文章,我将引入AOP的概念来将系统提高到更高的抽象层次。
(全文完)