别再用if-else了，用注解去代替他吧

旧城等待， 2023-10-14 10:28 10阅读 0赞

## 策略模式 ##

经常在网上看到一些名为“别再if-else走天下了”，“教你干掉if-else”等之类的文章，大部分都会讲到用策略模式去代替if-else。策略模式实现的方式也大同小异。主要是定义统一行为（接口或抽象类），并实现不同策略下的处理逻辑（对应实现类）。客户端使用时自己选择相应的处理类，利用工厂或其他方式。

### 注解实现 ###

本文要说的是用注解实现策略模式的方式，以及一些注意点。  
话不多说，还是以最常 见的订单处理为例。首先定义这样一个订单实体类：

@Data
    public class Order {
        /**
         * 订单来源
         */
        private String source;
        /**
         * 支付方式
         */
        private String payMethod;
        /**
         * 订单编号
         */
        private String code;
        /**
         * 订单金额
         */
        private BigDecimal amount;
        // ...其他的一些字段
    }

假如对于不同来源（pc端、移动端）的订单需要不同的逻辑处理。项目中一般会有OrderService这样一个类，如下，里面有一坨if-else的逻辑，目的是根据订单的来源的做不同的处理。

@Service
    public class OrderService {
    
        public void orderService(Order order) {
            if(order.getSource().equals("pc")){
                // 处理pc端订单的逻辑
            }else if(order.getSource().equals("mobile")){
                // 处理移动端订单的逻辑
            }else {
                // 其他逻辑
            }
        }
    }

策略模式就是要干掉上面的一坨if-else，使得代码看起来优雅且高大上。  
现在就让我们开始干掉这一坨if-else。先总览下结构：

![format_png][]

![Image 1][]

1.首先定义一个OrderHandler接口，此接口规定了处理订单的方法。

public interface OrderHandler {
        void handle(Order order);
    }

2.定义一个OrderHandlerType注解，来表示某个类是用来处理何种来源的订单。

@Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    @Documented
    @Service
    public @interface OrderHandlerType {
        String source();
    }

3.接下来就是实现pc端和移动端订单处理各自的handler，并加上我们所定义的OrderHandlerType注解。

@OrderHandlerType(source = "mobile")
    public class MobileOrderHandler implements OrderHandler {
        @Override
        public void handle(Order order) {
            System.out.println("处理移动端订单");
        }
    }
    
    @OrderHandlerType(source = "pc")
    public class PCOrderHandler implements OrderHandler {
        @Override
        public void handle(Order order) {
            System.out.println("处理PC端订单");
        }
    }

4.以上准备就绪后，就是向spring容器中注入各种订单处理的handler，并在OrderService.orderService方法中，通过策略（订单来源）去决定选择哪一个OrderHandler去处理订单。我们可以这样做：

@Service
    public class OrderService {
    
        private Map<String, OrderHandler> orderHandleMap;
    
        @Autowired
        public void setOrderHandleMap(List<OrderHandler> orderHandlers) {
            // 注入各种类型的订单处理类
            orderHandleMap = orderHandlers.stream().collect(
                    Collectors.toMap(orderHandler -> AnnotationUtils.findAnnotation(orderHandler.getClass(), OrderHandlerType.class).source(),
                            v -> v, (v1, v2) -> v1));
        }
    
        public void orderService(Order order) {
            // ...一些前置处理
    
            // 通过订单来源确定对应的handler
            OrderHandler orderHandler = orderHandleMap.get(order.getSource());
            orderHandler.handle(order);
    
            // ...一些后置处理
        }
    }

在OrderService中，维护了一个orderHandleMap，它的key为订单来源，value为对应的订单处理器Handler。通过@Autowired去初始化orderHandleMap（这里有一个lambda表达式，仔细看下其实没什么难度的）。这样一来，OrderService.orderService里的一坨if-else不见了，取而代之的仅仅是两行代码。即，先从orderHandleMap中根据订单来源获取对应的OrderHandler，然后执行OrderHandler.handle方法即可。  
这种做法的好处是，不论以后业务如何发展致使订单来源种类增加，OrderService的核心逻辑不会改变，我们只需要实现新增来源的OrderHandler即可，且团队中每人开发各自负责的订单来源对应的OrderHandler即可，彼此间互不干扰。

到此，似乎已经讲完了通过注解实现策略模式，干掉if-else的方法，就这样结束了吗？不，真正的重点从现在才开始。

现在回过头看orderHandleMap这个Map，它的key是订单来源，假如，我们想通过订单来源+订单支付方式这两个属性来决定到底使用哪一种OrderHandler怎么办？比如PC端支付宝支付的订单是一种处理逻辑（PCAliPayOrderHandler），PC端微信支付的订单是另外一种处理逻辑（PCWeChatOrderHandler），对应的还有移动端支付宝支付（MobileAliPayOrderHandler）和移动端微信支付（MobileWeChatOrderHandler）。

这时候我们的key应该存什么呢，可能有人会说，我直接存订单来源+订单支付方式组成的字符串不就行了吗？确实可以，但是如果这时业务逻辑又变了（向pm低头），PC端支付宝支付和微信支付是同一种处理逻辑，而移动端支付宝支付和微信支付是不同的处理逻辑，那情况就变成了PCAliPayOrderHandler和PCWeChatOrderHandler这两个类是同一套代码逻辑。我们干掉了if-else，但却造出了两份相同的代码，这是一个作为有强迫症的程序员所不能容忍的。怎么干掉这两个逻辑相同的类呢？

首先，我们可以回顾下，注解它究竟是个什么玩意？不知道大家有没有注意到定义注解的语法，也就是@interface，与定义接口的语法想比，仅仅多了一个@。翻看jdk，可以找到这么一个接口Annotation，如下

/**
     * The common interface extended by all annotation types.  Note that an
     * interface that manually extends this one does <i>not</i> define
     * an annotation type.  Also note that this interface does not itself
     * define an annotation type.
     *
     * More information about annotation types can be found in section 9.6 of
     * <cite>The Java™ Language Specification</cite>.
     *
     * The {@link java.lang.reflect.AnnotatedElement} interface discusses
     * compatibility concerns when evolving an annotation type from being
     * non-repeatable to being repeatable.
     *
     * @author  Josh Bloch
     * @since   1.5
     */
    public interface Annotation {
      // …省略
    }

开头就表明了，The common interface extended by all annotation types。说的很明白了，其实注解它就是个接口，对，它就是个接口而已，@interface仅仅是个语法糖。那么，注解既然是个接口，就必然会有相应的实现类，那实现类哪里来呢？上述中我们仅仅定义了OrderHandlerType注解，别的什么也没有做。这时候不得不提动态代理了，一定是jdk在背后为我们做了些什么。  
为了追踪JVM在运行过程中生成的JDK动态代理类。我们可以设置VM启动参数如下：

-Dsun.misc.ProxyGenerator.saveGeneratedFiles=true

该参数可以保存所生成的JDK动态代理类到本地。额外说一句，若我们想追踪cglib所生成的代理类，即对应的字节码文件，可以设置参数：

System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "保存的路径");

添加参数后再次启动项目，可以看到我们项目里多了许多class文件（这里只截取了部分，笔者启动的项目共生成了97个动态代理类。由于我的项目是springboot环境，因此生成了许多如ConditionalOnMissingBean、Configuration、Autowired等注解对应的代理类）：

![format_png 1][]

![Image 1][]

那接下来就是要找到我们所关心的，即jdk为我们自定义的OrderHandlerType注解所生成的代理类。由于jdk生成的动态代理类都会继承Proxy这个类，而java又是单继承的，所以，我们只需要找到实现了OrderHandlerType的类即可。遍历这些类文件，发现`$Proxy63`.class实现了我们定义的OrderHandlerType注解：

public final class $Proxy63 extends Proxy implements OrderHandlerType {
        private static Method m1;
        private static Method m2;
        private static Method m4;
        private static Method m3;
        private static Method m0;
    
        public $Proxy63(InvocationHandler var1) throws  {
            super(var1);
        }
    
        // …省略
    }

我们知道，jdk动态代理其实现的核心是：

![format_png 2][]

也就是这个构造函数的InvocationHandler对象了。那么注解的InvocationHandler是哪个具体实现呢？不难发现就是：

![format_png 3][]

![Image 1][]

这个类里面的核心属性，就是那个 memberValues，我们在使用注解时给注解属性的赋值，都存储在这个map里了。而代理类中的各种方法的实现，实际上是调用了 AnnotationInvocationHandler 里的 invoke 方法。  
好了，现在我们知道了注解就是个接口，且通过动态代理实现其中所定义的各种方法。那么回到我们的OrderService，为什么不把key的类型设置为OrderHandlerType？就像这样。

private Map<OrderHandlerType, OrderHandler> orderHandleMap;

如此一来，不管决定订单处理器orderhandler的因素怎么变，我们便可以以不变应万变（这不就是我们所追求的代码高扩展性和灵活性么）。那当我们的map的key变成了OrderHandlerType之后，注入和获取的逻辑就要相应改变，注入的地方很好改变，如下：

public class OrderService {
        private Map<OrderHandlerType, OrderHandler> orderHandleMap;
    
        @Autowired
        public void setOrderHandleMap(List<OrderHandler> orderHandlers) {
            // 注入各种类型的订单处理类
            orderHandleMap = orderHandlers.stream().collect(
                Collectors.toMap(orderHandler -> AnnotationUtils.findAnnotation(orderHandler.getClass(), OrderHandlerType.class),
                        v -> v, (v1, v2) -> v1));
        }
        // ...省略
    }

那获取的逻辑要怎么实现？我们怎么根据order的来源和支付方式去orderHandleMap里获取对应的OrderHandler呢？问题变成了如何关联order的来源和支付方式与OrderHandlerType注解。  
还记得刚才所说的注解就是个接口吗，既然是个接口，我们自己实现一个类不就完事了么，这样就把order的来源和支付方式与OrderHandlerType注解关联起来了。说干就干，现在我们有了这么一个类，

public class OrderHandlerTypeImpl implements OrderHandlerType {
    
        private String source;
        private String payMethod;
    
        OrderHandlerTypeImpl(String source, String payMethod) {
            this.source = source;
            this.payMethod = payMethod;
        }
    
        @Override
        public String source() {
            return source;
        }
    
        @Override
        public String payMethod() {
            return payMethod;
        }
    
        @Override
        public Class<? extends Annotation> annotationType() {
            return OrderHandlerType.class;
        }
    
    }

在获取对应OrderHandler时我们可以这样写，

public void orderService(Order order) {
        // ...一些前置处理
    
        // 通过订单来源确以及支付方式获取对应的handler
        OrderHandlerType orderHandlerType = new OrderHandlerTypeImpl(order.getSource(), order.getPayMethod());
        OrderHandler orderHandler = orderHandleMap.get(orderHandlerType);
        orderHandler.handle(order);
    
        // ...一些后置处理
    }

看起来没什么问题了，来运行一下。不对劲啊，空指针，那个异常它来了。

![Image 1][]

![format_png 4][]

我们断点打在NPE那一行，

![format_png 5][]

![Image 1][]

一定是姿势不对，漏掉了什么。那我们就来分析下。orderHandleMap中确实注入了所定义的几个OrderHandler（PCAliPayOrderHandler、PCWeChatOrderHandler、MobileAliPayOrderHandler、MobileWeChatOrderHandler），但是get却没有获取到，这是为什么呢？我们来回忆下，map的get方法逻辑，还记得最开始学习java时的hashCode和equals方法吗？  
不知道大家注意到没有，map中key对应的类型是$Proxy63（jdk动态代理给我们生成的），跟我们自己实现的OrderHandlerTypeImpl是不同类型的。  
梳理下，在Autowied时，我们放进orderHandleMap的key是动态代理类对象，而获取时，自定义了OrderHandlerTypeI实现类OrderHandlerTypeImpl，而又没有重写hashCode和equals方法，才导致从map中没有获取到我们所想要的OrderHandler，那么，我们把实现类OrderHandlerTypeImpl的hashCode和equals这两个方法重写，保持跟动态代理类生成的一样不就行了吗？再回看下动态代理给我们生成的这两个方法，前面说了，注解对应的代理类方法调用实际上都是AnnotationInvocationHandler里面的方法，翻看AnnotationInvocationHandler里面的hashCode和equals方法：

private int hashCodeImpl() {
        int var1 = 0;
        Entry var3;
        for(Iterator var2 = this.memberValues.entrySet().iterator(); var2.hasNext(); var1 += 127 * ((String)var3.getKey()).hashCode() ^ memberValueHashCode(var3.getValue())) {
            var3 = (Entry)var2.next();
        }
        return var1;
    }
    
    private Boolean equalsImpl(Object var1) {
        if (var1 == this) {
            return true;
        } else if (!this.type.isInstance(var1)) {
            return false;
        } else {
            Method[] var2 = this.getMemberMethods();
            int var3 = var2.length;
            for(int var4 = 0; var4 < var3; ++var4) {
                Method var5 = var2[var4];
                String var6 = var5.getName();
                Object var7 = this.memberValues.get(var6);
                Object var8 = null;
                AnnotationInvocationHandler var9 = this.asOneOfUs(var1);
                if (var9 != null) {
                    var8 = var9.memberValues.get(var6);
                } else {
                    try {
                        var8 = var5.invoke(var1);
                    } catch (InvocationTargetException var11) {
                        return false;
                    } catch (IllegalAccessException var12) {
                        throw new AssertionError(var12);
                    }
                }
                if (!memberValueEquals(var7, var8)) {
                    return false;
                }
            }
            return true;
        }
    }

具体的逻辑也比较简单，就不分析了。那我们就按照AnnotationInvocationHandler中的实现，在我们的OrderHandlerTypeImpl中按照相同的逻辑重写下这两个方法，如下

public class OrderHandlerTypeImpl implements OrderHandlerType {
    
        // …省略
    
        @Override
        public int hashCode() {
            int hashCode = 0;
            hashCode += (127 * "source".hashCode()) ^ source.hashCode();
            hashCode += (127 * "payMethod".hashCode()) ^ payMethod.hashCode();
            return hashCode;
        }
    
    
        @Override
        public boolean equals(Object obj) {
            if (!(obj instanceof OrderHandlerType)) {
                return false;
            }
            OrderHandlerType other = (OrderHandlerType) obj;
            return source.equals(other.source()) && payMethod.equals(other.payMethod());
        }
    }

再次运行看看是否达到我们预期，果不其然，这次可以正常获取到了handler，至此，大功告成。

![Image 1][]

![format_png 6][]

这样以来，不管以后业务怎么发展，OrderService核心逻辑不会改变，只需要扩展OrderHandler即可。

[format_png]: https://img-blog.csdnimg.cn/img_convert/41d65d2c771457c0e463282e29b6131f.webp?x-oss-process=image/format,png
[Image 1]: 
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/a13a44d46485f0dd213ea7493c9119d0.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/eef3e5cd8efd3e97d13b702d6b8a927a.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/050ceae316b7aedb79a19929e0689b1a.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/39a67f7dd34a4d781d0f20dd0a9332e6.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/5f0fba7154c9925205817bac2d470b2f.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/78583fd32f838c7fdfdf04abafd51b8b.webp?x-oss-process=image/format,png