Android事件总线编程的考虑

解耦设计实践
本文讨论了在实际项目开发中如何解决模块间高度耦合的问题,介绍了观察者模式和基于事件总线(EventBus)的编程方法,并通过购物网站下订单的例子详细阐述了这两种解耦方案的具体实现。

在实际项目开发中,经常会遇到当执行某个业务逻辑时,希望调用其他处理逻辑。

通常最简单粗暴的方法是直接依赖其他模块,调用模块相应方法,但这样会带来一些问题:

  • 模块间相互依赖,耦合度高。
  • 后期维护起来困难。
  • 代码缺少设计,不利于拓展。

下面的例子参考了事件驱动编程

举个例子:比如在购物网站,通常客户订单提交后,需要进行订单支付以及一些其他的业务处理,如发邮件通知客户下单成功等操作。 下面就这经典的购物网站下订单为例,探讨关于代码的编程设计几种思路:

高度耦合实现

订单模块直接依赖支付服务模块及用户服务模块,调用各模块的相应实现方法。由于模块间相互依赖,后期修改下订单逻辑时,则需要修改提交订单的代码,某些时候考虑到业务稳定性可能无法立即修改,也可能涉及到多处操作。

观察者模式实现

通过观察者模式来进行解耦,当被观察对象发生变化时,通知其观察者。观察者监听到相应的事件,由观察者实现相应的处理。体现在订单逻辑时:定义多个观察者观察下订单这个主题,当下订单的动作发生时,通知其所有观察者,再由每个观察者进行处理。

基于事件总线编程的实现

虽然观察者模式对源代码进行了解耦,但是还是有一些不足:

  • 相关模块需要实现相应接口;
  • 需要主动调用相关的addListener方法设置监听器;
  • 一个监听器智能监听一种操作。

EventBus是对于监听者模式的实现,通过EventBus事件总线来实现。 使用EventBus来实现监听者模式,只需要三步操作:

  • 通过注解@Subscribe来声明事件回调方法;
  • 调用EventBus的register方法来注册监听器;
  • 通过post方法来触发事件;

感谢: 事件驱动编程作者提供的思路,自己只是稍加进行了整理。

转载于:https://juejin.im/post/5a3522dd518825404d51d1e1

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值