过去参与的一个微信公众号开发的项目,其中处理被动响应消息的类相对臃肿,原因是该项目需要处理的消息类型较多,通过switch分支,分支方法都写在一个类里面。功能完成后,这个类就巨大无比了。闲来无事,就在想应该怎么重构一下呢?设计模式里面有解决大量if分支的状态模式,但是模式应用还没看明白。
想来,还是switch最直观的,为了便于维护,有必要把每个分支都抽取成一个处理类,同时做好包结构规划,虽然会形成大量短小的消息处理类,但是整体结构是清晰的。简单整理了下代码,类图如下:
原来全部代码都是写在RequestDispatcher里面的,现在则把其转化成N个短小的消息处理类,具体处理普通消息和事件消息。
/**
* 根据消息类型转发给对应的消息处理类
* @title RequestDispatcher
* @author WoodWang
* @description
* @date 2015-5-18
* @version 1.1.0
*/
public class RequestDispatcher {
public ResponseMsg doDispatcher(RequestMsg request){
//事件消息
if ("event".equals(request.getMsgType())) {
return dispatchEvent(request);
}
//普通消息
return dispatchMessage(request);
}
private ResponseMsg dispatchEvent(RequestMsg request){
ResponseMsg response = null;
EventType eventType = EventType.getEventType(request.getMsgType());
//根据事件类型,创建不同的处理类
switch(eventType){
case subscribe:
response = new SubscribeEventHandler().onEvent(request);
break;
case unsubscribe:
break;
case SCAN:
break;
}
return response;
}
private ResponseMsg dispatchMessage(RequestMsg request){
ResponseMsg response = null;
MsgType msgType = MsgType.getMsgType(request.getMsgType());
//根据消息类型,创建不同的处理类
switch(msgType){
case text:
response = new TextMsgHandler().onMsg(request);
break;
case image:
response = new ImageMsgHandler().onMsg(request);
break;
case link:
//TODO
case location:
//TODO
case video:
//TODO
case voice:
//TODO
}
return response;
}
}
每个具体消息处理类,遵循单一职责原则,完成一种消息的处理,例如TextMsgHandler:
public class TextMsgHandler {
/**
* 文本消息,响应格式为XML的文本信息
* @param msg
* @return
*/
public ResponseMsg onMsg(RequestMsg msg){
ResponseMsg response = null;
//TODO 解析请求消息内容,处理并返回
return response;
}
}
从最初的只关注功能实现,到开始关注代码结构、可读性,会考虑代码的执行效率,算不算是Coder的一个成熟表现呢?