手把手教你如何实现代码扩展点设计

　　引言
　　在我们写业务代码的时候，无可避免肯定会涉及到业务逻辑分支，从而写ifelse类似的语句。如果当前逻辑只有一个ifelse，则不会过度影响代码可读性，但是当if代码块的逻辑膨胀、else代码块的逻辑膨胀，那么整体代码的可读性就非常差，因为随着逻辑膨胀，ifelse代码块还会继续出现更多的ifelse。
　　正常情况下，初学者一般都会封装方法，即把if代码块的逻辑封装到另外一个方法里面，这样子看起来恢复了之前的样子，只有一个ifelse。但是，这样其实并没有解决根本问题：代码可读性差。因为在阅读代码的时候，还是会进入封装的方法内，然后方法内会有更多的ifelse等着你。随着逻辑分支的增多，人的脑力一般是无法同时记住之前的逻辑，所以整体代码的可读性还是很差。
　　那遇到这类问题，我们该如何解决呢？思路
　　根本原因是我们脑力无法去深入梳理逻辑，归纳逻辑，总是看后面忘了前面，那么如果我们把多个层级的逻辑梳理出来，归纳成单层级逻辑，那么整体的代码可读性就容易理解了。原来的多层级逻辑实例如下图：
　　类似这种，就是多层级逻辑结构，如果只是封装方法，那么作为代码阅读者就会陷入各种ifelse内部的方法跳转中，而无法从整体去理解业务。
　　那么基于这种常见的多层级逻辑，我们应该拆分为单层级逻辑，如下图：
　　这样子，我们在代码处理上，就可以拆分为1个业务逻辑处理接口、4个业务逻辑处理实现类，1个工厂类或者上下文类。然后在主逻辑代码块上通过工厂类获取封业务逻辑处理接口实例，然后调用处理方法。从而实现业务的封装和抽象，即把这块相关逻辑抽象为一个接口，不同的实现。下次如果再增加一个逻辑，则只要新增一个实现类，在工厂方法新增一个类型标识即可，主逻辑代码不变。实现方案一
　　这里以路边的地磁停车位为例，具体的线下业务是在停车场会安装一个地磁硬件，当有车进来的时候会上报一个车辆驶入事件，车出去的时候会上报一个车辆驶出事件，除了这2事件，当车位被占用或者空闲的时候，会上报2个心跳：持续占用和持续空闲
　　结合上面的业务，不同事件会有不同的处理方式，这里我们会创建一个状态处理接口，该接口有2个方法，一个返回状态枚举、一个处理方法，如下：publicinterfaceStateHandler｛DeviceStatusEnumstate（）；voidhandle（StringdeviceNo，Stringcode）；｝
　　然后，我们再创建一个工厂类或者叫上下文处理类，通过Spring的构造器注入所有实现StateHandler接口的实现类，然后放入当前实例的缓存map中，另外还提供一个根据枚举返回处理器的方法，具体如下：ComponentpublicclassStateContext｛publicMapDeviceStatusEnum，StateHandlerstateMapnewHashMap（）；publicStateContext（ListStateHandlerstateHandlerList）｛stateHandlerList。forEach（handler｛stateMap。put（handler。state（），handler）；｝）；｝publicStateHandlergetHandler（DeviceStatusEnumstate）｛returnstateMap。get（state）；｝｝
　　接下来就是具体状态的处理实现类，这里只放车辆驶出的处理类，如下：ComponentpublicclassOutStateHandlerimplementsStateHandler｛OverridepublicDeviceStatusEnumstate（）｛returnDeviceStatusEnum。OUT；｝Overridepublicvoidhandle（StringdeviceNo，Stringcode）｛TODO｝｝
　　这样子，在主逻辑代码只要根据状态类型，从工厂类获取处理器类，然后执行方法即可，如下：DeviceStatusEnumstateDeviceStatusEnum。get（status。getStatus（））；StateHandlerhandlerstateContext。getHandler（state）；handler。handle（request。getSN（），request。getBerthCode（））；
　　这样子即可消除对应的ifelse问题
　　通过上述的方案一，我们实现了消除基本的ifelse，但是我们再深入思考下，方案一会有什么问题？很明显，这是针对具体业务的一个实现方式，该实现方式需要1个上下文类、1个接口、对应的N个实现类，那么当我们的业务代码有多个不同业务的ifelse，每个业务都需要创建2N个类，造成了类膨胀。
　　所以，针对该问题，我们还需要对上述的实现方式进行抽象，让它更实用。实现方案二（最终解决方案）
　　通过对方案一实现的思考，我们可以对以下几个点进行优化
　　针对接口类，我们可以抽象不同业务的接口，该接口只有一个方法，用于返回具体某个业务的枚举类针对枚举类，不同业务会有不同的枚举类，而枚举类的抽象就是他们的父类：Enum针对上下文类，原来的map缓存key是具体某个枚举类，value是不同的实现类；而这里为了实现多个业务扩展点，我们key可以设计为枚举类的父类Enum，value为不同实现类的列表
　　具体的代码如下：
　　1。创建一个抽象接口，用于返回具体某个业务的枚举类publicinterfaceIExtensionHandlerYextendsEnum｛Yextension（）；｝
　　这里的泛型Y就是具体某个业务的枚举类
　　2。创建一个上下文类的接口，并实现其默认实现publicinterfaceIExtensionHandlerFactory｛添加扩展处理器paramextensionHandler处理器paramY扩展点YextendsEnumYvoidaddExtensionHandler（IExtensionHandlerYextensionHandler）；获取扩展点处理器paramextension扩展点paramtype处理器类型paramT扩展处理器paramY扩展点TextendsIExtensionHandlerY，YextendsEnumYTgetExtensionHandler（Yextension，ClassTtype）；｝
　　上下文类的默认实现Slf4jpublicclassDefaultExtensionHandlerFactoryImplimplementsIExtensionHandlerFactory，ApplicationContextAware｛privatefinalMapEnum，ListIExtensionHandlerserviceListCachenewConcurrentHashMap（）；privatefinalMapExtensionCacheKey，IExtensionHandlerserviceCachenewConcurrentHashMap（）；OverridepublicYextendsEnumYvoidaddExtensionHandler（IExtensionHandlerYextensionHandler）｛Assert。notNull（extensionHandler。extension（），addextensionhandlerfailed，beanclassextensionHandler。getClass（）。getName（）extensionisnull）；serviceListCache。putIfAbsent（extensionHandler。extension（），newLinkedList（））；serviceListCache。get（extensionHandler。extension（））。add（extensionHandler）；｝OverridepublicTextendsIExtensionHandlerY，YextendsEnumYTgetExtensionHandler（Yextension，ClassTtype）｛ExtensionCacheKeyYcacheKeynewExtensionCacheKey（extension，type）；IExtensionHandlerresultthis。serviceCache。get（cacheKey）；if（resultnull）｛ListIExtensionHandlerextensionHandlersserviceListCache。getOrDefault（extension，Collections。synchronizedList（Collections。emptyList（）））；for（IExtensionHandlerextensionHandler：extensionHandlers）｛if（type。isAssignableFrom（extensionHandler。getClass（）））｛resultextensionHandler；serviceCache。put（cacheKey，result）；break；｝｝if（resultnull）｛log。warn（NoIExtensionHandlerfoundbyCacheKey：cacheKey！）；｝｝return（T）result；｝OverridepublicvoidsetApplicationContext（ApplicationContextapplicationContext）throwsBeansException｛MapString，IExtensionHandlerhandlerMapapplicationContext。getBeansOfType（IExtensionHandler。class）；log。info（疯狂加载扩展ing。。。）；longstartSystem。currentTimeMillis（）；handlerMap。forEach（（k，v）｛排除组合类自己if（！this。getClass（）。isAssignableFrom（v。getClass（）））｛addExtensionHandler（v）；｝｝）；longendSystem。currentTimeMillis（）；log。info（加载扩展点结束，耗时：｛｝，扩展点个数：｛｝，endstart，handlerMap。size（））；｝｝
　　在默认的上下文实现类中，我们还多了一个Map，该Map是为了提高扩展点的查找而设计的，如果只是使用serviceListCache，那么每次根据某个业务的枚举类会返回对应的扩展处理器列表，需要再循环一次才能找到对应的处理器，这里是设计了一个缓存Key：ExtensionCacheKey，代码实现如下DataAllArgsConstructorToStringEqualsAndHashCodepublicclassExtensionCacheKeyTextendsEnum｛privateTextension；privateClasslt；？extendsIExtensionHandlerTextensionHandlerClass；｝
　　一个业务枚举类，可能会有不同类型的扩展处理接口，serviceListCache的value值为什么设计成List和为什么需要设计一个ExtensionCacheKey的原因所在。最后
　　这个扩展点设计虽然简单，但是在我实践的项目中有大量的使用，也推荐大家理解并使用，对于复杂业务的处理非常有帮助。
　　另外扩展点设计还有另外一种方式，基于注解的方式，具体实现可以搜下COLA4。0
　　获取完整源码地址：https：gitee。comanyinshirototoken