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

举报
且听风吟 发表于 2019/10/28 20:28:51 2019/10/28
【摘要】 这次分享一点实际开发中会用到的小技巧,教你简单的优化过多的if else。

前言

这次分享一点实际开发中会用到的小技巧,请耐心往下看。

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

image.png

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

比如这样:

20.jpg

摘自 cim 中的一个客户端命令的判断条件。

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

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

21.jpg

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

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

32.jpg

33.jpg

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

实现

22.jpg

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

整体思路如下:

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

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

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

  • 执行最终的 process 函数。

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

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

23.jpg

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

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

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

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

24.jpg

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

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

image.png

总结

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

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

如果if else是需要顺序执行的,

例:   

    if(x< 5){

        ……

    }else if(x<10){

        ……

    }else if(x<15){

        ……

    }

这样的话可读性变得稍有点差,而且复杂的if else几乎很少复用,此种优化就显得稍稍有些不适合。

所以对有顺序的if else,不适合这种优化。可读性和灵活性往往是互相矛盾的,就像看spring 的源码也会觉得不好理解,因为它才真的大量运用设计模式。

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

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

https://github.com/crossoverJie/cim

本文转载自微信公众号【java学习之道】。

原文链接:https://mp.weixin.qq.com/s?__biz=MzU4NzYwNDAwMg==&mid=2247484863&idx=1&sn=5e32da7a6276ce721b2a306cfbc6d2a7&chksm=fde8ccf2ca9f45e453062426707911e9de27046872607ca5897e21bd9186674deaa78c09c444&scene=0#rd


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。