现有平台的listener使用方法需要先获取billDefineId,根据billDefineId判断是哪种单据,然后做相应的业务逻辑。这种模式导致现有代码里中有很多if elseif 判断。一个listener可以处理多种不同的billDefineId。违反了软件开发中类的单一职责原则,一个listener承担了过多的职责,导致维护和阅读很困难。而且对于单一billDefineId,同一事件可能出现在不同的listener类,导致无法知晓某个billDefineId,某个事件,执行的业务逻辑遍布在哪些类。如下图:
同时存在很多相同的代码没有做到提取出来。提取出来的好处:1.供开发人员使用,提高开发效率 2.同一入口,一改俱改。对于现状,先改进如下
以往的代码如下:
现在改成如下:
现有的模式,强迫开发人员,监听只能对某一类billdefineId,某一类事件处理。使得监听职责单一,便于维护和阅读。同时AbstractEventHandler抽象类提供了很多辅助方法供开发人员使用。
实现原理:在spring容器启动时,会扫描包下面的两类注解@EventService @WfEventService,注入到spring容器中
在默认的listener实现处理分发到相应的监听处理类去处理。
为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线。当需求变化时,该变化会反映为类的职责的变化。如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个。
如果一个类承担的职责过多,就等于把这些职责耦合在了一起。一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。