现有listener改造方案

本文探讨了软件开发中的单一职责原则,指出原有代码中listener类承担了过多职责,导致维护困难。通过重构,将不同billDefineId的处理逻辑分离到单独的类,减少了if-else判断,提高了代码可读性和可维护性。同时,引入AbstractEventHandler抽象类提供辅助方法,简化开发工作。重构后,每个类职责更加单一,当需求变化时,影响范围更小,降低了系统复杂性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

现有平台的listener使用方法需要先获取billDefineId,根据billDefineId判断是哪种单据,然后做相应的业务逻辑。这种模式导致现有代码里中有很多if elseif 判断。一个listener可以处理多种不同的billDefineId。违反了软件开发中类的单一职责原则,一个listener承担了过多的职责,导致维护和阅读很困难。而且对于单一billDefineId,同一事件可能出现在不同的listener类,导致无法知晓某个billDefineId,某个事件,执行的业务逻辑遍布在哪些类。如下图:

同时存在很多相同的代码没有做到提取出来。提取出来的好处:1.供开发人员使用,提高开发效率 2.同一入口,一改俱改。对于现状,先改进如下

以往的代码如下:

      现在改成如下:

         现有的模式,强迫开发人员,监听只能对某一类billdefineId,某一类事件处理。使得监听职责单一,便于维护和阅读。同时AbstractEventHandler抽象类提供了很多辅助方法供开发人员使用。

实现原理:在spring容器启动时,会扫描包下面的两类注解@EventService @WfEventService,注入到spring容器中

在默认的listener实现处理分发到相应的监听处理类去处理。

为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线。当需求变化时,该变化会反映为类的职责的变化。如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个。

如果一个类承担的职责过多,就等于把这些职责耦合在了一起。一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值