过去参与的一个微信公众号开发的项目,其中处理被动响应消息的类相对臃肿,原因是该项目需要处理的消息类型较多,通过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的一个成熟表现呢?
原文地址:http://blog.csdn.net/wojiushiwo945you/article/details/45815073