过去参与的一个微信公众号开发的项目，其中处理被动响应消息的类相对臃肿，原因是该项目需要处理的消息类型较多，通过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;
	}
}

public class TextMsgHandler {
	/**
	 * 文本消息，响应格式为XML的文本信息
	 * @param msg
	 * @return
	 */
	public ResponseMsg onMsg(RequestMsg msg){
		ResponseMsg response = null;
		//TODO 解析请求消息内容，处理并返回
		return response;
	}
}

项目开发-微信公众号被动响应消息处理