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

前言

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

好比平时你们是否都会写相似这样的代码：

if(a){ //dosomething }else if(b){ //doshomething }else if(c){ //doshomething } else{ ////doshomething }

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

好比这样：

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

 

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

刚开始条件较少，也就没管那么多直接写的；如今功能多了致使每次新增一个 else 条件我都得仔细核对，生怕影响以前的逻辑。

此次终于忍无可忍就把他重构了，重构以后这里的结构以下：

 

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

而以前全部的实现逻辑都单独抽取到其余实现类中。

 

 

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

实现

 

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

总体思路以下：

• 定义一个 InnerCommand 接口，其中有一个 process 函数交给具体的业务实现。
• 根据本身的业务，会有多个类实现 InnerCommand 接口；这些实现类都会注册到 Spring Bean 容器中供以后使用。
• 经过客户端输入命令，从 Spring Bean 容器中获取一个 InnerCommand 实例。
• 执行最终的 process 函数。

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

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

 

• 第一步是获取全部的 InnerCommand 实例列表。
• 根据客户端输入的命令从第一步的实例列表中获取类类型。
• 根据类类型从 Spring 容器中获取具体实例对象。

所以首先第一步须要维护各个命令所对应的类类型。

 

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

因此在以前的枚举中就维护了命令和类类型的关系，只须要知道命令就能知道他的类类型。

这样才能知足只须要两行代码就能替换之前复杂的 if else，同时也能灵活扩展。

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

总结

固然还能够作的更灵活一些，好比都不须要显式的维护命令和类类型的对应关系。

只须要在应用启动时扫描全部实现了 InnerCommand 接口的类便可。

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。