查看原文
其他

利用策略模式优化过多 if else 代码

crossoverJie 开源中国 2019-04-28

本文经授权转载自 crossoverJie(ID:crossoverJie)

前言

本次来一点实际开发中会用到的小技巧。

比如平时大家是否都会写类似这样的代码:

  1. if(a){

  2.    //dosomething

  3. }else if(b){

  4.    //doshomething

  5. }else if(c){

  6.    //doshomething

  7. } else{

  8.    ////doshomething

  9. }

条件少还好,一旦 elseif 过多这里的逻辑将会比较混乱,并很容易出错。

比如这样:

摘自 cim(https://github.com/crossoverJie/cim) 中的一个客户端命令的判断条件。

刚开始条件较少,也就没管那么多直接写的;现在功能多了导致每次新增一个 else 条件我都得仔细核对,生怕影响之前的逻辑。

这次终于忍无可忍就把他重构了,重构之后这里的结构如下:

最后直接变为两行代码,简洁了许多。

而之前所有的实现逻辑都单独抽取到其他实现类中。

这样每当我需要新增一个 else 逻辑,只需要新增一个类实现同一个接口便可完成。每个处理逻辑都互相独立互不干扰。

实现

按照目前的实现画了一个草图。

整体思路如下:

  • 定义一个 InnerCommand 接口,其中有一个 process 函数交给具体的业务实现。

  • 根据自己的业务,会有多个类实现 InnerCommand 接口;这些实现类都会注册到 SpringBean 容器中供之后使用。

  • 通过客户端输入命令,从 SpringBean 容器中获取一个 InnerCommand 实例。

  • 执行最终的 process 函数。

主要想实现的目的就是不在有多个判断条件,只需要根据当前客户端的状态动态的获取 InnerCommand 实例。

从源码上来看最主要的就是 InnerCommandContext 类,他会根据当前客户端命令动态获取 InnerCommand 实例。

  • 第一步是获取所有的 InnerCommand 实例列表。

  • 根据客户端输入的命令从第一步的实例列表中获取类类型。

  • 根据类类型从 Spring 容器中获取具体实例对象。

因此首先第一步需要维护各个命令所对应的类类型。

所以在之前的枚举中就维护了命令和类类型的关系,只需要知道命令就能知道他的类类型。

这样才能满足只需要两行代码就能替换以前复杂的 ifelse,同时也能灵活扩展。

  1. InnerCommand instance = innerCommandContext.getInstance(msg);

  2. instance.process(msg) ;

总结

当然还可以做的更灵活一些,比如都不需要显式的维护命令和类类型的对应关系。

只需要在应用启动时扫描所有实现了 InnerCommand 接口的类即可,在 cicada 中有类似实现,感兴趣的可以自行查看(https://github.com/TogetherOS/cicada)。

这样一些小技巧希望对你有所帮助。

以上所有源码可以在这里查看:

https://github.com/crossoverJie/cim


开源中国征稿开始啦!


开源中国 www.oschina.net 是目前备受关注、具有强大影响力的开源技术社区,拥有超过 200 万的开源技术精英。我们传播开源的理念,推广开源项目,为 IT 开发者提供一个发现、使用、并交流开源技术的平台。


现在我们开始对外征稿啦!如果你有优秀的技术文章想要分享,热点的行业资讯需要报道等等,欢迎联系开源中国进行投稿。投稿详情及联系方式请参见:我要投稿


推荐阅读

和 jQuery 说再见,Bootstrap 5 将移除对其依赖

大厂小厂都在搞开源,它真的能赚钱?

微软宣布 Visual Studio 2019 将于4月2日正式发布

与 30 家公司过招,得到了这章面试心法

PYPL 二月榜单发布:最受欢迎的编程语言、IDE 和数据库都是哪些?

「好看」一下,分享给更多人↓↓↓

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存