如果熟悉C#语言的小伙伴们一般都会知道委托、事件的好处,只需在某个类中提前定义好公开的委托或事件(委托的特殊表现形式)变量,然后在其它类中就可以很随意的订阅该委托或事件,当委托或事件被触发执行时,会自动通知所有的订阅者进行消费处理。(观察者模式用委托来实现是最好不过了,DDD所提倡的事件驱动其根本理念也是如此),当然我这里想到的是不需要在每个类中进行定义委托或事件,而是由一个统一的中介者(即EventPublishSubscribeUtils)来提供事件的订阅及发布操作,这样各模块之间无需直接依赖,只需通过中介者完成发布通知与订阅回调即可,何乐而不为呢?

这里我先借助C#语言独有的委托类型快速实现了一个简易的EventPublishSubscribeUtils,代码如下:

  1. /// <summary>
  2. /// 自定义事件发布订阅回调工具类(业务解藕、关注点分离,避免互相依赖)--演示版
  3. /// EventBus简化版,观察者模式
  4. /// author:zuowenjun
  5. /// </summary>
  6. public static class EventPublishSubscribeUtils
  7. {
  8. private static ConcurrentDictionary<Type, EventHandler<object>> EventHandlers { get; } = new ConcurrentDictionary<Type, EventHandler<object>>();
  9. private static void removeRegisters(ref EventHandler<object> srcEvents, EventHandler<object> removeTargetEvents)
  10. {
  11. var evtTypes = removeTargetEvents.GetInvocationList().Select(d => d.GetType());
  12. var registeredEventHandlers = Delegate.Combine(srcEvents.GetInvocationList().Where(ei => evtTypes.Contains(ei.GetType())).ToArray());
  13. srcEvents -= (EventHandler<object>)registeredEventHandlers;
  14. }
  15. public static void Register<T>(EventHandler<object> eventHandlers)
  16. {
  17. EventHandlers.AddOrUpdate(typeof(T), eventHandlers,
  18. (t, e) =>
  19. {
  20. //先根据订阅委托类型匹匹配过滤掉之前已有的相同订阅,然后再重新订阅,防止重复订阅,多次执行的情况。
  21. removeRegisters(ref e, eventHandlers);
  22. e += eventHandlers;
  23. return e;
  24. });
  25. }
  26. public static void UnRegister<T>(EventHandler<object> eventHandlers = null)
  27. {
  28. Type eventMsgType = typeof(T);
  29. if (eventHandlers == null)
  30. {
  31. EventHandlers.TryRemove(eventMsgType, out eventHandlers);
  32. return;
  33. }
  34. var e = EventHandlers[eventMsgType];
  35. removeRegisters(ref e, eventHandlers);
  36. }
  37. public static void PublishEvent<T>(T eventMsg, object sender)
  38. {
  39. Type eventMsgType = eventMsg.GetType();
  40. if (EventHandlers.ContainsKey(eventMsgType))
  41. {
  42. EventHandlers[eventMsgType].Invoke(sender, eventMsg);
  43. }
  44. }
  45. }

然后使用就比较简单了,我们只需通过EventPublishSubscribeUtils.Register注册订阅事件消息,通过EventPublishSubscribeUtils.PublishEvent发布事件通知,这样就可以让两个甚至多个不相关的模块(类)能够通过消息类型实现1对多的通讯与协同处理。使用示例代码如下:

  1. class EventMessage
  2. {
  3. public string Name { get; set; }
  4. public string Msg { get; set; }
  5. public DateTime CreatedDate { get; set; }
  6. }
  7. class DemoA
  8. {
  9. public DemoA()
  10. {
  11. EventHandler<object> eventHandlers = EventCallback1;
  12. eventHandlers += EventCallback2;
  13. EventPublishSubscribeUtils.Register<EventMessage>(eventHandlers);
  14. }
  15. private void EventCallback1(object sender, object e)
  16. {
  17. string json = JsonConvert.SerializeObject(e);
  18. System.Diagnostics.Debug.WriteLine($"EventCallback1=> sender:{sender},e:{json}");
  19. }
  20. private void EventCallback2(object sender, object e)
  21. {
  22. string json = JsonConvert.SerializeObject(e);
  23. System.Diagnostics.Debug.WriteLine($"EventCallback2=> sender:{sender},e:{json}");
  24. }
  25. }
  26. class DemoB
  27. {
  28. public void ShowMsg(string name, string msg)
  29. {
  30. System.Diagnostics.Debug.WriteLine($"ShowMsg=> name:{name},msg:{msg}");
  31. var eventMsg = new EventMessage
  32. {
  33. Name = name,
  34. Msg = msg,
  35. CreatedDate = DateTime.Now
  36. };
  37. EventPublishSubscribeUtils.PublishEvent(eventMsg, nameof(DemoB.ShowMsg));
  38. }
  39. }
  40. //main方法中使用:
  41. var demoA = new DemoA();
  42. var demoB = new DemoB();
  43. demoB.ShowMsg("梦在旅途", "i love csharp and java!");

从上述示例代码中可以看出,DemoA与DemoB各为独立,互不依赖,它们都不知道有对方的存在,它们只关心业务的处理,通过执行demoB.ShowMsg方法进而触发回调demoA.EventCallback1,demoA.EventCallback2方法,是不是比起直接从DemoA中调DemoB更好呢?

c#有委托类型(方法的引用),那如果是在java中该如何实现呢?

其实同理,我们可以借助匿名内部类+匿名实现类的方式(如:函数式接口)实现与C#异曲同工的效果,同样可以实现类似的事件发布与订阅功能,如下便是采用java语言的实现EventPublishSubscribeUtils类的代码:

这个因项目需要,我特意实现了两种模式,一种支持1对多的普通方式,另一种支持1对1的订阅回调方式,有返回值。

  1. /**
  2. * 自定义事件发布订阅回调工具类(业务解藕、关注点分离,避免互相依赖)
  3. * EventBus简化版,观察者模式
  4. * <pre>
  5. * 支持两种模式
  6. * 1.无返回值:订阅事件消费(register)+ 发布事件消息(publishEvent/publishEventAsync)
  7. * 2.有返回值:监听回调通知处理(listenCallback)+通知回调(notifyCallback),通过notifyMessageType+MessageChannel 即可标识唯一的一组通知回调与监听回调处理
  8. * <pre>
  9. * @author zuowenjun
  10. * @date 20200310
  11. */
  12. public final class EventPublishSubscribeUtils {
  13. private static final Logger LOGGER = LoggerFactory.getLogger(EventPublishSubscribeUtils.class);
  14. private static final Map<Class<?>, LinkedList<Consumer<Object>>> eventConsumers = new ConcurrentHashMap<>();
  15. private static final Map<Class<?>, ConcurrentHashMap<MessageChannel, Function<Object, Object>>> callbackFuncs = new ConcurrentHashMap<>();
  16. private EventPublishSubscribeUtils() {
  17. }
  18. /**
  19. * 注册事件回调消费者
  20. * 用法:EventSubscribeConsumeUtils.register(this::xxxx方法) 或lambda表达式
  21. * 注意:若回调方法添加了事务注解,则应指派其代理对象的方法来完成回调,如:
  22. * EventSubscribeConsumeUtils.register((xxxService)SpringUtils.getBean(this.class)::xxxx方法)
  23. *
  24. * @param eventConsumer
  25. */
  26. public static void register(Class<?> eventMessageType, Consumer<Object> eventConsumer) {
  27. if (eventConsumer == null) {
  28. return;
  29. }
  30. LinkedList<Consumer<Object>> eventConsumerItems = null;
  31. if (!eventConsumers.containsKey(eventMessageType)) {
  32. eventConsumers.putIfAbsent(eventMessageType, new LinkedList<>());
  33. }
  34. eventConsumerItems = eventConsumers.get(eventMessageType);
  35. eventConsumerItems.add(eventConsumer);
  36. }
  37. /**
  38. * 取消订阅回调
  39. *
  40. * @param eventMessageType
  41. * @param eventConsumer
  42. */
  43. public static void unRegister(Class<?> eventMessageType, Consumer<Object> eventConsumer) {
  44. if (!eventConsumers.containsKey(eventMessageType)) {
  45. return;
  46. }
  47. LinkedList<Consumer<Object>> eventConsumerItems = eventConsumers.get(eventMessageType);
  48. int eventConsumerIndex = eventConsumerItems.indexOf(eventConsumer);
  49. if (eventConsumerIndex == -1) {
  50. return;
  51. }
  52. eventConsumerItems.remove(eventConsumerIndex);
  53. }
  54. /**
  55. * 发布事件,同步触发执行回调事件消费者方法(存在阻塞等待),即事件消息生产者
  56. * 用法:在需要触发事件消息回调时调用,如:publishEvent(eventMessage);
  57. *
  58. * @param eventMessage
  59. */
  60. public static <T> void publishEvent(T eventMessage) {
  61. Class<?> eventMessageType = eventMessage.getClass();
  62. if (!eventConsumers.containsKey(eventMessageType)) {
  63. return;
  64. }
  65. LOGGER.info("事件已发布,正在执行通知消费:{}", JSONObject.toJSONString(eventMessage));
  66. for (Consumer<Object> eventConsumer : eventConsumers.get(eventMessageType)) {
  67. try {
  68. eventConsumer.accept(eventMessage);
  69. } catch (Exception ex) {
  70. LOGGER.error("eventConsumer.accept error:{},eventMessageType:{},eventMessage:{}",
  71. ex, eventMessageType, JSONObject.toJSONString(eventMessage));
  72. }
  73. }
  74. }
  75. /**
  76. * 发布事件,异步触发执行回调事件消费者方法(异步非阻塞),即事件消息生产者
  77. * 用法:在需要触发事件消息回调时调用,如:publishEventAsync(eventMessage);
  78. *
  79. * @param eventMessage
  80. */
  81. public static <T> void publishEventAsync(final T eventMessage) {
  82. Executor asyncTaskExecutor = (Executor) SpringUtils.getBean("asyncTaskExecutor");
  83. asyncTaskExecutor.execute(() -> {
  84. publishEvent(eventMessage);
  85. });
  86. }
  87. /**
  88. * 监听回调处理(需要有返回值),即有返回值的回调消费者
  89. *
  90. * @param notifyMessageType
  91. * @param messageChannel
  92. * @param callbackFunc
  93. */
  94. public static void listenCallback(Class<?> notifyMessageType, MessageChannel messageChannel, Function<Object, Object> callbackFunc) {
  95. if (!callbackFuncs.containsKey(notifyMessageType)) {
  96. callbackFuncs.putIfAbsent(notifyMessageType, new ConcurrentHashMap<>());
  97. }
  98. Map<MessageChannel, Function<Object, Object>> functionMap = callbackFuncs.get(notifyMessageType);
  99. if (!functionMap.containsKey(messageChannel)) {
  100. functionMap.putIfAbsent(messageChannel, callbackFunc);
  101. } else {
  102. LOGGER.error("该通知消息类型:{}+消息通道:{},已被订阅监听,重复订阅监听无效!", notifyMessageType.getSimpleName(), messageChannel.getDescription());
  103. }
  104. }
  105. /**
  106. * 通知回调(同步等待获取监听回调的处理结果),即生产者
  107. *
  108. * @param notifyMessage
  109. * @param messageChannel
  110. * @param <R>
  111. * @return
  112. */
  113. @SuppressWarnings("unchecked")
  114. public static <R> R notifyCallback(Object notifyMessage, MessageChannel messageChannel) {
  115. Class<?> notifyMessageType = notifyMessage.getClass();
  116. Map<MessageChannel, Function<Object, Object>> functionMap = callbackFuncs.getOrDefault(notifyMessageType, null);
  117. if (functionMap != null) {
  118. Function<Object, Object> callbackFunction = functionMap.getOrDefault(messageChannel, null);
  119. if (callbackFunction != null) {
  120. LOGGER.info("通知回调消息已发布,正在执行回调处理:{},messageChannel:[{}]", JSONObject.toJSONString(notifyMessage), messageChannel.getDescription());
  121. Object result = callbackFunction.apply(notifyMessage);
  122. try {
  123. return (R) result;
  124. } catch (ClassCastException castEx) {
  125. throw new ClassCastException(String.format("监听回调处理后返回值实际类型与发布通知回调待接收的值预期类型不一致,导致类型转换失败:%s," +
  126. "请确保notifyCallback与listenCallback针对通知消息类型:%s+消息通道:%s返回值类型必需一致。",
  127. castEx.getMessage(), notifyMessageType.getSimpleName(), messageChannel.getDescription()));
  128. }
  129. }
  130. }
  131. return null;
  132. }
  133. }

当然如果需要实现1对1的通讯,除了指定消息类型外,还需要指定消息通讯通道(即:唯一标识),目的是可以实现同一种消息类型,支持不同的点对点的处理。

  1. /**
  2. * 自定义消息通道
  3. * 作用:用于识别同一个消息类型下不同的监听回调者(notifyMessage+messageChannel 即可标识唯一的一组通知回调[生产者]与监听回调[消费者])
  4. * @author zuowenjun
  5. * @date 2020-03-31
  6. */
  7. public enum MessageChannel {
  8. None("无效"),
  9. MSG_A("测试消息A"),
  10. ;
  11. private String description;
  12. MessageChannel(String description) {
  13. this.description=description;
  14. }
  15. public String getDescription() {
  16. return description;
  17. }
  18. }

使用方法示例代码如下:

  1. @Service
  2. public class DemoAService {
  3. private static final Logger LOGGER = LoggerFactory.getLogger(DemoAService.class);
  4. public void showMsg(String name, String msg) {
  5. System.out.printf("【%1$tF %1$tT.%1$tL】hello!%s,DemoAService showMsg:%s %n", new Date(), name, msg);
  6. EventMessage eventMessage = new EventMessage();
  7. eventMessage.setName("aaa");
  8. eventMessage.setMsg("test");
  9. eventMessage.setCreatedDate(new Date());
  10. EventPublishSubscribeUtils.publishEvent(eventMessage);
  11. String msgJsonStr = EventPublishSubscribeUtils.notifyCallback(eventMessage, MessageChannel.MSG_A);
  12. System.out.printf("【%1$tF %1$tT.%1$tL】DemoAService showMsg notifyCallback json result:%2$s %n", new Date(), msgJsonStr);
  13. }
  14. }
  15. @Service
  16. public class DemoBService {
  17. @Autowired
  18. private DemoAService demoAService;
  19. @PostConstruct
  20. public void init(){
  21. //订阅消费,无返回值,支持1对多,即:同一个消息类型可同时被多个消费者订阅
  22. EventPublishSubscribeUtils.register(EventMessage.class,this::showFinishedMsg);
  23. //订阅监听回调,有返回值,只能1对1
  24. EventPublishSubscribeUtils.listenCallback(EventMessage.class, MessageChannel.MSG_A,this::getMsgCallbak);
  25. }
  26. private void showFinishedMsg(Object eventMsg){
  27. EventMessage eventMessage=(EventMessage)eventMsg;
  28. System.out.printf("【%1$tF %1$tT.%1$tL】%s,receive msg:%s doing...%n",
  29. eventMessage.getCreatedDate(),eventMessage.getName(),eventMessage.getMsg());
  30. //模拟逻辑处理
  31. try {
  32. Thread.sleep(500L);
  33. } catch (InterruptedException e) {
  34. e.printStackTrace();
  35. }
  36. System.out.printf("【%1$tF %1$tT.%1$tL】%s,do finished!!!%n",new Date(),eventMessage.getName());
  37. }
  38. private String getMsgCallbak(Object eventMsg){
  39. EventMessage eventMessage=(EventMessage)eventMsg;
  40. eventMessage.setMsg(eventMessage.getMsg()+"--callback added!");
  41. eventMessage.setCreatedDate(new Date());
  42. System.out.printf("【%1$tF %1$tT.%1$tL】%s,do msg callback!!!%n",new Date(),eventMessage.getName());
  43. return JSONObject.toJSONString(eventMessage);
  44. }
  45. }

如上代码所示,我们借助于EventPublishSubscribeUtils,解耦了两个Service Bean之间的依赖,避免了循环依赖的问题,去掉了之前为了解决循环依赖而使用@Lazy注解的方式,更易于扩展与更改。其实Spring底层也使用了类似的Event机制,说明这种方式还是有合适的用武之地的。

这里我通过简单的关系图来对比未引用EventPublishSubscribeUtils前与引用后的区别,大家可以感受一下哪种更方便:
之前:

之后:

最后,关于业务解耦,分清业务边界,我个人认为跨进程通讯使用MQ,同进程跨多模块(类,或者说跨多业务边界)可使用Event事件驱动思路来解决。大家觉得如何呢?如果有更好的方案欢迎评论交流,谢谢。

版权声明:本文为zuowj原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/zuowj/p/12810016.html