如何实现代码扩展点设计(扩展操作码设计要点有哪些)

2241阅读模式

引言

在我们写业务代码的时候,无可避免肯定会涉及到业务逻辑分支,从而写if-else类似的语句。如果当前逻辑只有一个if-else,则不会过度影响代码可读性,但是当if 代码块的逻辑膨胀、else代码块的逻辑膨胀,那么整体代码的可读性就非常差,因为随着逻辑膨胀,if-else 代码块还会继续出现更多的if-else。文章源自懂站帝-http://www.sfdkj.com/12492.html

正常情况下,初学者一般都会封装方法,即把if代码块的逻辑封装到另外一个方法里面,这样子看起来恢复了之前的样子,只有一个if-else。但是,这样其实并没有解决根本问题:代码可读性差。 因为在阅读代码的时候,还是会进入封装的方法内,然后方法内会有更多的if-else等着你。随着逻辑分支的增多,人的脑力一般是无法同时记住之前的逻辑,所以整体代码的可读性还是很差。文章源自懂站帝-http://www.sfdkj.com/12492.html

那遇到这类问题,我们该如何解决呢?文章源自懂站帝-http://www.sfdkj.com/12492.html

思路

根本原因是我们脑力无法去深入梳理逻辑,归纳逻辑,总是看后面忘了前面,那么如果我们把多个层级的逻辑梳理出来,归纳成单层级逻辑,那么整体的代码可读性就容易理解了。原来的多层级逻辑实例如下图:文章源自懂站帝-http://www.sfdkj.com/12492.html

如何实现代码扩展点设计(扩展操作码设计要点有哪些)

文章源自懂站帝-http://www.sfdkj.com/12492.html

类似这种,就是多层级逻辑结构,如果只是封装方法,那么作为代码阅读者就会陷入各种if else 内部的方法跳转中,而无法从整体去理解业务。文章源自懂站帝-http://www.sfdkj.com/12492.html

那么基于这种常见的多层级逻辑,我们应该拆分为单层级逻辑,如下图:文章源自懂站帝-http://www.sfdkj.com/12492.html

如何实现代码扩展点设计(扩展操作码设计要点有哪些)

文章源自懂站帝-http://www.sfdkj.com/12492.html

这样子,我们在代码处理上,就可以拆分为1个业务逻辑处理接口、4个业务逻辑处理实现类,1个工厂类或者上下文类。 然后在主逻辑代码块上通过工厂类获取封业务逻辑处理接口实例,然后调用处理方法。从而实现业务的封装和抽象,即把这块相关逻辑抽象为一个接口,不同的实现。下次如果再增加一个逻辑,则只要新增一个实现类,在工厂方法新增一个类型标识即可,主逻辑代码不变。文章源自懂站帝-http://www.sfdkj.com/12492.html

实现方案一

这里以路边的地磁停车位为例,具体的线下业务是在停车场会安装一个地磁硬件,当有车进来的时候会上报一个车辆驶入事件,车出去的时候会上报一个车辆驶出事件,除了这2事件,当车位被占用或者空闲的时候,会上报2个心跳:持续占用和持续空闲文章源自懂站帝-http://www.sfdkj.com/12492.html

结合上面的业务,不同事件会有不同的处理方式,这里我们会创建一个状态处理接口,该接口有2个方法,一个返回状态枚举、一个处理方法,如下:文章源自懂站帝-http://www.sfdkj.com/12492.html

public interface StateHandler {


    DeviceStatusEnum state();


    void handle(String deviceNo, String code);
}

然后,我们再创建一个工厂类或者叫上下文处理类,通过Spring的构造器注入所有实现StateHandler接口的实现类,然后放入当前实例的缓存map中,另外还提供一个根据枚举返回处理器的方法,具体如下:文章源自懂站帝-http://www.sfdkj.com/12492.html

@Component
public class StateContext {


    public Map<DeviceStatusEnum, StateHandler> stateMap = new HashMap<>();


    public StateContext(List<StateHandler> stateHandlerList){
        stateHandlerList.forEach(handler -> {
            stateMap.put(handler.state(), handler);
        });
    }


    public StateHandler getHandler(DeviceStatusEnum state){
        return stateMap.get(state);
    }
}

接下来就是具体状态的处理实现类,这里只放车辆驶出的处理类,如下:文章源自懂站帝-http://www.sfdkj.com/12492.html

@Component
public class OutStateHandler implements StateHandler{
    @Override
    public DeviceStatusEnum state() {
        return DeviceStatusEnum.OUT;
    }


    @Override
    public void handle(String deviceNo, String code) {
        // TODO
    }
}

这样子,在主逻辑代码只要根据状态类型,从工厂类获取处理器类,然后执行方法即可,如下:文章源自懂站帝-http://www.sfdkj.com/12492.html

DeviceStatusEnum state = DeviceStatusEnum.get(status.getStatus());
StateHandler handler = stateContext.getHandler(state);
handler.handle(request.getSN(), request.getBerthCode());

这样子即可消除对应的if-else文章源自懂站帝-http://www.sfdkj.com/12492.html

问题

通过上述的方案一,我们实现了消除基本的if-else,但是我们再深入思考下,方案一会有什么问题? 很明显,这是针对具体业务的一个实现方式,该实现方式需要1个上下文类、1个接口、对应的N个实现类,那么当我们的业务代码有多个不同业务的if-else,每个业务都需要创建2+N个类,造成了类膨胀。文章源自懂站帝-http://www.sfdkj.com/12492.html

所以,针对该问题,我们还需要对上述的实现方式进行抽象,让它更实用 。文章源自懂站帝-http://www.sfdkj.com/12492.html

实现方案二(最终解决方案)

通过对方案一实现的思考,我们可以对以下几个点进行优化文章源自懂站帝-http://www.sfdkj.com/12492.html

•针对接口类,我们可以抽象不同业务的接口,该接口只有一个方法,用于返回具体某个业务的枚举类•针对枚举类,不同业务会有不同的枚举类,而枚举类的抽象就是他们的父类:Enum•针对上下文类,原来的map缓存key是具体某个枚举类,value是不同的实现类;而这里为了实现多个业务扩展点,我们key可以设计为枚举类的父类Enum,value为不同实现类的列表文章源自懂站帝-http://www.sfdkj.com/12492.html

具体的代码如下:文章源自懂站帝-http://www.sfdkj.com/12492.html

1.创建一个抽象接口,用于返回具体某个业务的枚举类文章源自懂站帝-http://www.sfdkj.com/12492.html

public interface IExtensionHandler<Y extends Enum>{
 Y extension();
}

这里的泛型Y就是具体某个业务的枚举类文章源自懂站帝-http://www.sfdkj.com/12492.html

2.创建一个上下文类的接口,并实现其默认实现文章源自懂站帝-http://www.sfdkj.com/12492.html

public interface IExtensionHandlerFactory {
 /**
  * 添加扩展处理器
  * @param extensionHandler 处理器
  * @param <Y> 扩展点
  */
 <Y extends Enum<Y>>void addExtensionHandler(IExtensionHandler<Y> extensionHandler);


 /**
  * 获取扩展点处理器
  * @param extension 扩展点
  * @param type 处理器类型
  * @param <T> 扩展处理器
  * @param <Y> 扩展点
  */
 <T extends IExtensionHandler<Y>,Y extends Enum<Y>> T getExtensionHandler(Y extension, Class<T> type);
}

上下文类的默认实现文章源自懂站帝-http://www.sfdkj.com/12492.html

@Slf4j
public class DefaultExtensionHandlerFactoryImpl implements IExtensionHandlerFactory, ApplicationContextAware {


    private final Map<Enum, List<IExtensionHandler>> serviceListCache = new ConcurrentHashMap<>();
    private final Map<ExtensionCacheKey, IExtensionHandler> serviceCache = new ConcurrentHashMap<>();


    @Override
    public <Y extends Enum<Y>> void addExtensionHandler(IExtensionHandler<Y> extensionHandler) {
        Assert.notNull(extensionHandler.extension(), "add extension handler failed, bean class " + extensionHandler.getClass().getName() + " extension is null");
        serviceListCache.putIfAbsent(extensionHandler.extension(), new LinkedList<>());
        serviceListCache.get(extensionHandler.extension()).add(extensionHandler);
    }


    @Override
    public <T extends IExtensionHandler<Y>, Y extends Enum<Y>> T getExtensionHandler(Y extension, Class<T> type) {
        ExtensionCacheKey<Y> cacheKey = new ExtensionCacheKey(extension, type);
        IExtensionHandler result = this.serviceCache.get(cacheKey);
        if (result == null) {
            List<IExtensionHandler> extensionHandlers = serviceListCache.getOrDefault(extension, Collections.synchronizedList(Collections.emptyList()));
            for (IExtensionHandler extensionHandler : extensionHandlers) {
                if (type.isAssignableFrom(extensionHandler.getClass())) {
                    result = extensionHandler;
                    serviceCache.put(cacheKey, result);
                    break;
                }
            }
            if (result == null) {
                log.warn("No IExtensionHandler found by CacheKey : " + cacheKey + " !");
            }
        }
        return (T) result;
    }


    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        Map<String,IExtensionHandler> handlerMap = applicationContext.getBeansOfType(IExtensionHandler.class);
        log.info("疯狂加载扩展ing ...");
        long start = System.currentTimeMillis();
        handlerMap.forEach((k, v) -> {
            //排除组合类自己
            if (!this.getClass().isAssignableFrom(v.getClass())) {
                addExtensionHandler(v);
            }
        });
        long end = System.currentTimeMillis();
        log.info("加载扩展点结束,耗时: {}, 扩展点个数: {}", end - start, handlerMap.size());
    }
}

在默认的上下文实现类中,我们还多了一个Map,该Map是为了提高扩展点的查找而设计的,如果只是使用serviceListCache,那么每次根据某个业务的枚举类会返回对应的扩展处理器列表,需要再循环一次才能找到对应的处理器,这里是设计了一个缓存Key: ExtensionCacheKey, 代码实现如下文章源自懂站帝-http://www.sfdkj.com/12492.html

@Data
@AllArgsConstructor
@ToString
@EqualsAndHashCode
public class ExtensionCacheKey<T extends Enum> {


    private T extension;
    private Class<? extends IExtensionHandler<T>> extensionHandlerClass;
}

一个业务枚举类,可能会有不同类型的扩展处理接口,serviceListCache的value值为什么设计成List和为什么需要设计一个ExtensionCacheKey的原因所在。文章源自懂站帝-http://www.sfdkj.com/12492.html

最后

这个扩展点设计虽然简单,但是在我实践的项目中有大量的使用,也推荐大家理解并使用,对于复杂业务的处理非常有帮助。文章源自懂站帝-http://www.sfdkj.com/12492.html

另外扩展点设计还有另外一种方式,基于注解的方式,具体实现可以搜下 COLA 4.0文章源自懂站帝-http://www.sfdkj.com/12492.html

获取完整源码地址:https://gitee.com/anyin/shiro-to-token文章源自懂站帝-http://www.sfdkj.com/12492.html

懂站帝
  • 本文由 发表于 2022年4月18日 12:40:34
  • 版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至395045033@qq.com举报,一经查实,本站将立刻删除。