最近看到一個應用，雖然代碼量不大，但設計卻很新穎，有種麻雀雖小，五髒俱全的感覺，在這跟大家分享下
先看下大致結構：
其中
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采用何種方式來解析，也許會更好些。
