一个可以代替冗长switch-case的消息分发小框架

在项目中，我需要维护一个应用层的字节流协议。这个协议的每条报文都是一个字节数组，数组的头两个字节表示消息的传送方向，第三、四个字节表示消息ID，也就是消息种类，再往后是消息内容、时间戳、校验码等……整个消息看起来差不多长这样：

Message Head	Message ID	Content	Timestamp	Checksum
2 bytes	2 bytes	n bytes	8 bytes	1 byte

Message ID指定了消息类型，根据不同的消息类型，对Content有不同的解析方法。在处理报文的类中，我们不得不用一个switch-case结构去处理不同类型的报文：

   switch(messageID){
           case 0x01: doSomething();  break;
           case 0x02: doAnotherThing(); break;
           case 0x03: doSomeOtherThing(); break;
           ...
 }

在某些报文的消息内容中还存在一个子消息ID，这个子ID会定义具体要实现的操作分类。于是在switch-case中，我们还要再加入嵌套的switch-case去处理对应的子ID：

 switch(messageID){
   case 0x01: doSomething();  break;
   case 0x02: doAnotherThing(); break;
   case 0x03:
   　　byte subID = getSubID();
     switch(subID)
     case 0x01: process1In3(); break;
     case 0x02: process2In3(); break;
     ...
     break;
   ...
 }

由于需求一直在变化，我们自身的功能也在演变，协议中经常会增减消息，对同一个消息的处理也常常会变化，渐渐地这个switch-case达到了300多行，而我经常要从这300多行中找到对应的消息去修改它的处理代码，稍不注意就会出错，真是苦不堪言。

一个大神同事提示我，可以用注解解决这个问题。定义一个Handler接口作为消息处理器，再定义一个注解去标示该处理器要处理的消息ID，然后提供一个Util类，利用反射机制读取注解，自动将不同的消息ID和对应的Handler加载到一个Map中，形成一个微型的消息分发处理框架。在这个框架的作用下，上面的switch-case语句变成了这样：

     //存放消息ID和对应的MessageHandler
     private Map<Byte, MessageHandler> handlersMap = null;
     void init() {
         //读取注解，将下列定义的HANDLER_1,2,3加载到handlersMap中
         handlersMap = MessageHandlerUtil.loadMessageHandlers(this);
     }

     //接收消息的回调函数
     public void onDataReceived(CommData command) {
         byte commandID = getCommandId(command);
         handlersMap.get(commandID).process(command);//调用对应的Handler处理
     }

     //消息ID为01的Handler
     @Handle(messageID=0x01)
     private final MessageHandler HANDLER_1 = (command) -> {    doSomething(); };
     //消息ID为02的Handler
     @Handle(messageID=0x02)
     private final MessageHandler HANDLER_2 = (command) -> { doAnotherThing(); };
     //消息ID为03的Handler
     @Handle(messageID=0x03)
     private final MessageHandler HANDLER_3 = (command) -> { doSomeOtherThing(); };

在这个微型框架之下，要实现报文解析，只需要准备一个HashMap，在初始化时调用MessageHandlerUtil.loadMessageHandlers(this)， MessageHandlerUtil这个辅助类会自动将类中所有带@Handle注解的MessageHandler加载到一个Map中并返回，用户在收到消息时，只需要从Map中拿到消息对应的Handler，调用Handler的process方法即可。在增减消息时，只需要增减带@Handle注解的MessageHandler；就算要修改某一个消息的处理，也能比较快速地定位到对应的Handler，在这个独立的Handler里面修改即可，比起之前的switch-case，可以说是更好地遵守了开放-封闭原则（对扩展开放，对更改封闭）。

不得不说，这个框架还是有一点小问题，那就是不能支持子消息的分类。在我负责的业务中，只有一个消息（记为A消息）有子消息，于是我偷懒定义了一个@SubHandle注解，在加载时将@SubHandler注解的MessageHandler加载到另一个Map中，当收到的消息为A消息时，再手动将对应的MessageHandler从第二个Map中取出。这种做法可以说是十分hard code了，还好我负责的业务比较固定，暂时还能用。另外，返回的HashMap是裸露的，用户可以随意修改，看起来似乎也不是很妥当。

周一来上班时，惊喜地发现大神把我的微型框架重构并加入了项目的通用类库中。重构后的框架加强了对数据结构的封装，并且实现了很强的通用性，可以支持三层以上的子消息结构，却只用了两个Map。下面我们就一起来看看他是怎么做的。

首先，还是通过客户代码来看一下这个框架的使用场景。（对于下面的分析，我们都假设消息是一个String类型以使叙述简洁。如果要处理byte数组或其他类型的消息，可以在客户代码中进行转型，或者像大神一样在框架中加入对byte数组的支持，在此就不赘述了）

   private HandlerDispatcher<String> handlerDispatcher;//消息分发器

   void init(){
         handlerDispatcher = new HandlerDispatcherImpl<>();
         handlerDispatcher.load(this); //将注解的Handler加载到分发器
   }

   public void onReceivedMessage(String data) {
       //第一个char为消息ID
       handlerDispatcher.getHandler(data.charAt(0)+"").process(data);
   }

   final Supplier<HandlerDispatcher<String>> supplier = () -> handlerDispatcher;

   @Mapped("1") //第一层，处理消息ID为1的消息
   final CustomizedHandler A = (data) -> { log("A"); };

   @Mapped("2") //第一层，处理消息ID为2的消息
   final ParentHandler<String> B = ParentHandler.build(supplier, (data) -> (data.charAt(1)+""));

   @Parent("B")
   @Mapped("1") //第二层，处理消息ID为2，子消息ID为1的消息
   final ParentHandler<String> B1 = ParentHandler.build(supplier, (data) -> (data.charAt(2)+""));

   @Parent("A")
   @Mapped("1") //第二层，处理消息ID为1，子消息ID也为1的消息
   final CustomizedHandler A1 = (data) -> { log("A1"); };

   @Parent("B1")
   @Mapped("1") //第三层，处理消息ID为1，子消息ID为2，子子消息ID为1的消息
   final CustomizedHandler B11 = (data) -> { log("B11"); };

示例中定义了三层消息的解析器，用@Mapped(value = messageID)注解定义对应的消息ID，只有该注解的是第一层消息的解析器，同时定义了@Mapped和@Parent注解的是第二层及以下的解析器，其中@Parent(value = parentName)定义了其父消息的解析器名称。

除了能支持多层子消息以外，新的设计将消息分发这个过程封装到了HandlerDispatcher类中，更好地符合了单一指责原则，这样业务模块就能更专心地处理业务逻辑了，而HandlerDispatcher的实现类也可以随时根据业务来调整消息分发的逻辑。

至于上文中的Supplier和ParentHandler.build()，此处可能暂时看不懂，但它们并不是很重要，可以先跳过。

既然说到了HandlerDispatcher，我们就来说一下这个小框架的类结构，其实十分简单：

图１：消息分发小框架类图

各个类的关系图中已经比较清楚了，核心类HandlerDispatcher负责加载和分发消息到对应的Handler。框架提供了一个ParentHandler接口供用户在有子消息的场景使用，该接口对上层接口Handler中的process（）方法做了默认实现：

     @Override
     default void process(T data) {
         getHandlerDispatcher().getSubHandler(this, resolve(data)).process(data);
     }

这是整个框架中我觉得比较聪明的地方之一，也或许是面向对象和面向过程的程序员的思维区别之一。在多级消息分发器的结构中，消息分发到下层的逻辑是由上层消息分发器定义的，而不是在用户模块中或者HandlerDispatcher中定义的。也就是说在整个框架中并没有一个全能选手统揽全局，每个对象都像流水线上的工人，只要把产品加工后传给下一个工人，就完成了自己的责任。

图2：消息分发结构示例

如果我们有一个上图所示的消息分发结构，那么顶层和中间层的消息处理器可以使用框架提供的ParentHandler，也可以使用自己定义的处理逻辑。如果使用ParentHandler，则process()方法会从HandlerDispatcher拿到当前Handle的子Handler进行处理，即自动实现了到下层的消息分发；如果用户需要一些特殊处理，比如分发到下层之前先打印出一些信息，或者要分发给多个子消息处理器，则可以继承ParentHandler并重写其中的process()方法，或者定义自己的Handler。

看到这里，我们应该已经基本熟悉了消息分发小框架的结构。下面我们来看一下HandlerDispatcher是如何加载和找到一个对应的Handler的。

在设计加载算法之前，再来复习一下使用场景：对于顶层消息，我们用handlerDispatcher.getHandler(getMessageIDSomehow()).process(data)来处理；顶层以下的消息，按照ParentHandler的默认实现，通过getHandlerDispatcher().getSubHandler(this, resolve(data)).process(data)处理。也就是说，HandlerDispatcher加载所有Handler之后需要达到两个效果， 一是通过messageID拿到顶层Handler，二是通过上层Handler和subID拿到对应的下层Handler。

对于第一点，只要用一个HashMap<String, Handler>就可以实现。第二点有点难办，考虑到消息的层级结构，我们先用一个树来保存不同层级的Handler。在加载时，读取@Parent来获取上下层级的对应关系。TreeNode类的定义如下：

 public class TreeNode<T> {
     T data;
     List<TreeNode<T>> children = new ArrayList<>();
     TreeNode<T> parent;

     public TreeNode(TreeNode<T> parent, T data){
         Objects.requireNonNull(parent);
         this.parent = parent;
         this.data = data;
         parent.children.add(this);
     }

     public TreeNode(T data){
         this.data = data;
     }

     public List<TreeNode<T>> getChildren() {
         return children;
     }

     public T getData() {
         return data;
     }
 }

图2示意的框架如果用TreeNode装载，可以表示如下：

以上只是简略图，实际上TreeNode<T>是一个泛型类，泛型T代表树节点中存储的数据。为了表示messageID与Handler的对应关系，我们还会设计一个NodeData类把两者都存放起来，而这个NodeData就成为TreeNode<T>中对应的T。

     class NodeData{
         Handler<V> handler;
         String key;

         public NodeData(String key, Handler<V> handler) {
             Objects.requireNonNull(key);
             this.key = key;
             this.handler = handler;
         }

         public boolean accept(String anotherKey){
             return anotherKey != null && key.equals(anotherKey);
         }

         public Handler<V> getHandler() {
             return handler;
         }
     }

按照TreeNode去存放后，我们就可以找到某一个父消息的子消息处理器了。但这样要求我们先遍历树，找到对应的父消息处理器；再遍历父消息处理器的孩子节点，找到子消息处理器。为了节省第一步的时间，我们把所有的父消息处理器和它们对应的树节点存在Map中，这样就可以直接按照父消息的id拿到父消息处理器了。

总结起来，我们一共设计了一个树，两个Map。将它们定义在HandlerDispatcherImpl类中作为私有域：

     private Map<String, Handler<V>> topMap;
     private Map<Handler<V>, TreeNode<NodeData>> nodeMap;
     private TreeNode<NodeData> root;

下面我们来看一下HandlerDispatcherImpl中的load方法是怎么把Handler加载到这三个数据结构的。

首先，我们按照刚才的设计，将带注释的域分为两类：带@Parent的和不带@Parent的，分别放入两个数组中。

         //Scan all fields
         Class<?> instanceClass = instance.getClass();
         Field[] fields = instanceClass.getDeclaredFields();
         List<Field> topHandlerFields = new LinkedList<>();
         List<Field> subHandlerFields = new LinkedList<>();

         //Find fields with "@Mapped" annotation, insert them into
         //topHandlerFields and subHandlerFields
         for(Field field : fields){
             Mapped mapped = field.getAnnotation(Mapped.class);
             if(mapped == null) continue;
             Class<?> fieldType = field.getType();
             if(!Handler.class.isAssignableFrom(fieldType))
                 continue;
             Parent parent = field.getAnnotation(Parent.class);
             if(parent == null) topHandlerFields.add(field);
             else subHandlerFields.add(field);
         }

注意，在这里我们对域类型做了一个判断，只有域是Handler的实现类时才会被加载，否则会被无视。

将所有域加载到两个数组中以后，首先处理顶层消息对应的域，把它们放到topMap中，同时也把对应的树节点存在nodeMap中。

         //insert topHandlerFields into topMap; link them with tree
         topHandlerFields.forEach(field -> {
             String key = extractKeyFromField(field);
             try {
                 field.setAccessible(true);
                 Handler<V> handler = (Handler<V>) field.get(instance);
                 topMap.put(key, handler);
                 NodeData nodeData = new NodeData(key, handler);
                 TreeNode<NodeData> treeNode = new TreeNode<NodeData>(root, nodeData);
                 nodeMap.put(handler, treeNode);
             } catch (IllegalArgumentException | IllegalAccessException e) {
                 e.printStackTrace(out);
             }
         });

然后处理非顶层消息的处理器域。这里，考虑到用户不一定是按由顶向下的顺序定义的，加载时可能先读取到子处理器，后读取父处理器，这样就无法有效地形成一个完整的树结构。于是我们采用一种循环加载的方式，先加载父节点已在树中的处理器，并将已加载的域放在一个叫processed的链表中做记录；父节点还没有被加载的那些处理器留待下一次循环时再尝试加载。（不得不佩服大神同事的考虑十分周到……）

         //link subHandlerFields with tree
         List<Field> processed = new LinkedList<>();
         while(processed.size() < subHandlerFields.size()){
             subHandlerFields.stream().filter(field -> !processed.contains(field)).forEach(field -> {
                 linkWithParent(field, processed, instance);
             });
         }

     private void linkWithParent(Field field, List<Field> processed, Object instance) {
         field.setAccessible(true);
         Class<?> instanceClass = instance.getClass();
         //Firstly, see if we could find parent field
         String key = extractKeyFromField(field);
         String parentName = field.getAnnotation(Parent.class).value();
         Field parentHandlerField = null;
         try {
             parentHandlerField = instanceClass.getDeclaredField(parentName);
         } catch (NoSuchFieldException | SecurityException e) {
             log("Dude, your parent " + parentName + " doesn't exist.");
             processed.add(field);
             e.printStackTrace(); return;
         }
         //Try to get parentHandler, and its corresponding value in nodeMap
         try {
             parentHandlerField.setAccessible(true);
             Handler<V> parentHandler = (Handler<V>) parentHandlerField.get(instance);
             TreeNode<NodeData> parentNode = nodeMap.get(parentHandler);
             if(parentNode == null){
                 log("Parent " + parentName + " of field " + field + " not processed yet. Will wait a while.");
                 return;
             }
             //Add subHandler as a child to parentHandler
             Handler<V> subHandler = null;
             subHandler = (Handler<V>) field.get(instance);
             NodeData subHandlerNodeData = new NodeData(key, subHandler);
             TreeNode<NodeData> childNode = new TreeNode<>(parentNode, subHandlerNodeData);
             nodeMap.put(subHandler, childNode);
             processed.add(field);
             log("Attached " + field);
         }catch (IllegalArgumentException | IllegalAccessException e) {
             //should not happen
             e.printStackTrace(out);
             processed.add(field);
         }
     }

搞定了加载，我们再来看看获取。顶层Handler的获取十分容易，只要从Map拿一下就好了：

     public Handler<V> getHandler(String key) {
         return topMap.get(key);
     }

获取子Handler也不难，先从nodeMap中找到父节点对应的树节点，然后遍历其子节点就可以了。

     public Handler<V> getSubHandler(Handler<V> parentHandler, String subKey) {
         TreeNode<NodeData> parentNode = nodeMap.get(parentHandler);
         final Predicate<TreeNode<NodeData>> SUBHANDLER_ACCEPTS_KEY = (treeNode) -> (
                 ((NodeData)treeNode.getData()).accept(subKey)
         );
         Result<TreeNode<NodeData>> result = new Result<>();
         parentNode.getChildren().stream().filter(SUBHANDLER_ACCEPTS_KEY).findFirst().ifPresent(result::set);
         return result.isNULL() ? null : result.get().getData().getHandler();
     }

至此，我们基本完成了消息加载的小框架的核心代码啦。现在再看看开头的的示例程序中，我们看不懂的那一部分：

   final Supplier<HandlerDispatcher<String>> supplier = () -> handlerDispatcher;

   @Mapped("2") //第一层，处理消息ID为2的消息
   final ParentHandler<String> B = ParentHandler.build(supplier, (data) -> (data.charAt(1)+""));

这里有两个问题。第一是ParentHandler.build。其实这是一个静态Util方法，用于快速生成一个ParentHandler的实现类。看一下这个方法的定义：

     static <T> ParentHandler<T> build(final Supplier<HandlerDispatcher<T>> supplier, Resolver<T> resolver){
         ParentHandler<T> parentHandler = new ParentHandler<T>(){

             @Override
             public String resolve(T data) {
                 return resolver.apply(data);
             }

             @Override
             public HandlerDispatcher<T> getHandlerDispatcher() {
                 return supplier.get();
             }

         };
         return parentHandler;
     }

这里的Resolver是一个简单的接口，它的定义如下：

 public interface Resolver<T> extends Function<T, String>{}

其实它就是一个Function接口，功能是输入消息类型T返回String，即定义一个返回子消息ID的方法。在build方法定义的ParentHandler中，通过resolver.apply(data)即可返回子消息的ID。

第二个问题是supplier。Supplier<T>类型是Java 1.8引进的一个接口，它的功能与Function类似，返回一个T类型，在这里我们定义它为HandlerDispatcher的供应者，它返回的用户定义的一个HandlerDispatcher对象。那么为什么不能直接用HandlerDispatcher对象呢？

我们先来复习一下Java类初始化的顺序：

1. 当用户创建某类的对象或使用该类的静态变量/方法时，Java解释器会在classpath中寻找.class文件并加载。
2. 进行所有的静态初始化。即某一个类的静态初始化只进行一次。
3. 在内存堆中按需分配该对象的内存。
4. 初始化该类的所有非静态变量至0或null。
5. 按照类中变量的定义对变量进行初始化。
6. 调用构造函数。

注意步骤5和6，JVM是先对类中的域进行初始化，再调用构造函数的。在我们的用户模块中，所有的Handler都定义为对象中的域，所以它们会先被初始化。而

 handlerDispatcher = new HandlerDispatcherImpl<>();

是在构造函数中才被调用的。也就是说，如果我们不使用Supplier，我们必须要这么写：

 @Mapped("2") //第一层，处理消息ID为2的消息
final ParentHandler<String> B = ParentHandler.build(handlerDispatcher, (data) -> (data.charAt(1)+""));

可是这里的handlerDispatcher是一个空指针。那么后续再通过handlerDispatcher查找子处理器的时候，会抛出空指针错误。

supplier定义了一个拿到handlerDispatcher对象的方法。虽然在定义supplier时，handlerDispatcher也是空的，但是由于我们传进去的是一个方法，所以没关系。

通过学习大神的代码，除了学到了一点大神的设计思路，还了解了一些Java 1.8的新特性，如流式编程和函数式编程，同时心里也产生了许多疑问。对于这些疑问，就让我们在以后的文章中慢慢道来吧。

消息分发小框架源码：戳这里