文档章节

求求你别再用if-else了,用注解去代替他吧

o
 osc_sdc55qra
发布于 07/01 12:25
字数 2982
阅读 30
收藏 0

精选30+云产品,助力企业轻松上云!>>>

策略模式

经常在网上看到一些名为“别再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。先总览下结构:

 

在这里插入图片描述

 

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&trade; 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等注解对应的代理类):

 

在这里插入图片描述 那接下来就是要找到我们所关心的,即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动态代理其实现的核心是:

 

在这里插入图片描述

 

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

 

在这里插入图片描述 这个类里面的核心属性,就是那个 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); // ...一些后置处理 } 

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

 

在这里插入图片描述

 

我们断点打在NPE那一行,

在这里插入图片描述

 

一定是姿势不对,漏掉了什么。那我们就来分析下。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,至此,大功告成。

 

在这里插入图片描述

 

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

如果大家觉得这篇文章对你有帮助,你的关注和转发是对我最大的支持,O(∩_∩)O:




o
粉丝 0
博文 64
码字总数 0
作品 0
私信 提问
加载中
请先登录后再评论。

暂无文章

SequoiaDB监控与开发实践分析

使用背景 公司近期上线了一个新应用,底层数据库采用了国产的分布式数据库 – SequoiaDB。 因为需要将 SequoiaDB 集群纳入到公司的整个监控体系中,所以需要对 SequoiaDB 的状态、性能指标等...

巨杉数据库
33分钟前
6
0
如何导入其他Python文件? - How to import other Python files?

问题: How do I import other files in Python? 如何在Python中导入其他文件? How exactly can I import a specific python file like import file.py ? 我究竟该如何导入特定的python文件......

fyin1314
42分钟前
22
0
小程序上传图片 返回的地址出现回车空格问题

不知怎么回事 ,今天写小程序上传图片 之前是没问题的,今天突然出现很多回车空格问题 那怎么办呢,处理呗 //去掉空格str = str.replace(/\ +/g,""); console.log(str);//"{'retmsg':'suc......

子枫Eric
52分钟前
6
0
Spring Boot + Spring Security自定义用户认证

自定义认证过程 自定义认证的过程需要实现Spring Security提供的UserDetailService接口 ,源码如下: public interface UserDetailsService { UserDetails loadUserByUsername(String use...

心田已荒
今天
12
0
DateTime2与SQL Server中的DateTime - DateTime2 vs DateTime in SQL Server

问题: Which one: 哪一个: datetime datetime2 is the recommended way to store date and time in SQL Server 2008+? 是在SQL Server 2008+中存储日期和时间的推荐方法吗? I'm aware of......

富含淀粉
今天
13
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部