消息模式

最近看到一个应用，虽然代码量不大，但设计却很新颖，有种麻雀虽小，五脏俱全的感觉，在这跟大家分享下
 
 
 
 
先看下大致结构：
 

 
 
其中
 
1. AsyncWorker：抽象的业务接口，提供了doWork方法，具体的业务处理逻辑由子类来封装
 
 
2. AbstractNapoliWorker<T>：总控制器
 
a） 定义泛型，由子类来控制解析出来的消息类型，自由灵活。
 
b）对doWork方法初步实现，引入了一些控制逻辑
 
 
 
[html] view plaincopyprint?
public boolean doWork(Serializable msg) {  
  
        // 1. 解析消息  
        T destMessageBean = parseMessage(msg);  
        // 2. 消息过滤  
        if (filterMessage(destMessageBean)) {  
            // 3. 业务处理  
            doBiz(destMessageBean);  
        }  
  
        return true;  
    }  
 
public boolean doWork(Serializable msg) {
 
        // 1. 解析消息
        T destMessageBean = parseMessage(msg);
        // 2. 消息过滤
        if (filterMessage(destMessageBean)) {
            // 3. 业务处理
            doBiz(destMessageBean);
        }
 
        return true;
    }
注：代码示例中的filterMessage方法、doBiz方法都是空实现的，只是为保证基本流程的通畅性。具体的业务逻辑由子类来实现 
 
3. MailSendWorker：子控制器
 
a）传输具体的泛型模板
 
b）对filterMessage方法、doBiz方法具体实现
 
4.  MailProcessMessage：原子执行器。有针对性的处理不同的业务（N种不同流程）
 
 
 
 
总结：结构还是比较清晰的，不同的业务也可以交给不同的原子执行器处理，互不干扰，日后如果有新的流程接入，也可以快速接入，但是也有点小不足。
 
 
 
 
 
[html]  
protected T parseMessage(Serializable msg) {  
       if (msg == null) {  
           return null;  
       }  
  
       if (msg instanceof String) {  
          //业务处理  
       return ...;  
       }   
       return null;  
   }  
 
 protected T parseMessage(Serializable msg) {
        if (msg == null) {
            return null;
        }
 
        if (msg instanceof String) {
           //业务处理
  return ...;
        } 
        return null;
    }
 
 
 
parseMessage方法，控制的过死，每一种类型（如：String）只能按一种方式来解析，不灵活，如果入参再增加一个类型参数，用于控制msg采用何种方式来解析，也许会更好些。

补充：软件开发 , C++ ,