前言ifelse太多了，一般用策略模式重构，策略模式也很简单。首先定义一个接口，各个处理分支实现这个接口，定义条件->处理类映射关系，然后根据条件找到对应的处理类并执行。当有新的分支时，只需要添加一个接口实现类，只需要添加一个条件->映射类的映射关系即可。介绍还是很通俗易懂的，没什么惊喜。这应该是一年前的最后一次分享了。这一次，我将介绍一些在实际开发中会用到的技巧。比如你平时是不是写这样的代码：条件少点还好，但是一旦elseif多了，这里的逻辑就会混乱，容易出错。例如，这是cim中一个客户端命令的判断条件的摘录。一开始条件很少，所以没在意那么多直接写；现在功能多了，每次加else条件都要仔细检查，生怕影响前面的逻辑。这次终于忍无可忍，重构了他。重构之后，这里的结构如下：最后直接变成两行代码，简单多了。之前的所有实现逻辑都被单独提取到其他实现类中。这样，每当我需要添加一个else逻辑时，只需要添加一个新的类来实现相同的接口即可。各个处理逻辑相互独立，互不干扰。实现根据当前实现画草图。总体思路如下：定义一个InnerCommand接口，里面有一个流程函数交给具体的业务实现。根据自己的业务，会有多个实现了InnerCommand接口的类；这些实现类会被注册到SpringBean容器中，以备后用。通过客户端输入命令，从SpringBean容器中获取一个InnerCommand实例。执行最后的流程功能。主要目的是不再有判断条件，只需要根据当前client的状态动态获取InnerCommand实例即可。从源码来看，最重要的是InnerCommandContext类，它会根据当前客户端命令动态获取InnerCommand实例。第一步是获取所有InnerCommand实例的列表。根据客户端输入的命令，第一步从实例列表中获取类类型。根据类类型，从Spring容器中获取具体的实例对象。因此，第一步是维护每个命令对应的类类型。所以在前面的枚举中保持了命令和类类型的关系，只有知道命令才能知道类类型。这样只需要两行代码就可以代替之前复杂的ifelse，还可以灵活扩展。总结当然可以做得更灵活，比如不需要显式维护命令和类类型的对应关系。您只需要在应用程序启动时扫描所有实现了InnerCommand接口的类。cicada中也有类似的实现，感兴趣的可以自行查看。希望这些小技巧可以帮到你。GitHub地址：https://github.com/crossoverJie/cim
