Java 代码 switch 分支过多，怎么改写比较优雅呢？

[NoKey]

一个收到消息，分发给不同的处理方法的代码

消息类型已经有十几种了

使用 switch 来根据消息类型跳转不同的处理方法

这个 switch 看起来就很庞大了

请教一下，有没有很好的方式来重构这种情况的代码呢

谢谢~

[7911364440]

策略模式啊

[dddd1919]

典型的工厂模式

[yaodao]

如果 switch 中的内容比较简单，可以使用枚举类实现抽象方法的简单策略模式。如果比较复杂可以使用监听者模式，广播消息，但每个监听者只处理自己相应的消息。

[TWorldIsNButThis]

使用语言内建的 dispatch 功能
也就是子类型多态

[ql562482472]

switch 都写不优雅 你到底写成啥样了 发出来看看吧

[ashong]

handlers[event].action()

[xiangagou]

最通用的就是工厂+策略模式修改,几乎不用动脑子,其他模式得看业务匹配情况

[ashong]

@ashong 看错了😅

[nothingistrue]

十几种还不算多，如果能做成枚举的话，switch 枚举并无不妥。如果太多做不成枚举，或者稍微有那么一两个变异的分支，用 if else 也不丢人。你要知道，你后面的处理是分发不同方法，那么就算有 50 个，代码行也就 150 行，不多。

这里的重点，还是你的消息类型的命名规则。消息类型如果是依次罗列命名，超过 10 个就麻烦，超过 20 个就没法用了。基本上，超过 20 个类型，就该考虑对消息类型的名称进行归纳分级。如果消息类型有良好的命名规则，消息分发可能就不需要 swtich 、if else 了，十几行代码就能搞定。

[cosmain]

@nothingistrue 一看就是老 coder 了

[fredli]

抽象类继承，消息子类，多态

[zhady009]

每个消息类型对应一个 ActionChain, Action 对应具体的业务
关于消息类型和 ActionChain 的关系建立可以是硬编码, 也可以用 Spring 的 BeanPostProcessor+注解的方式

[lysS]

信息类型是确定的，可以用数组

[lyusantu]

保持 switch 写法
写完后折叠 switch 看起来就比较优雅了

[ianEros]

复杂一点写策略，简单逻辑表驱动

[NoKey]

@ql562482472 就是 switch 下面十几个 case ，可能还会增长，到一定时候，肯定不好看，一大片的 case😂

[lambdAlan]

策略模式加工厂模式即可

[ianEros]

Map<?, Function<?> action> actionsMap = new HashMap<>();

// 初试配置对应动作
actionsMap.put(value1, (someParams) -> { doAction1(someParams)});
actionsMap.put(value2, (someParams) -> { doAction2(someParams)});
actionsMap.put(value3, (someParams) -> { doAction3(someParams)});

// 省略 null 判断
actionsMap.get(param).apply(someParams);

[NoKey]

@lyusantu 看不见就好了么？🤣

[libook]

除非消息类型划分不合理，或者重复处理逻辑太多，否则不认为 switch 分枝多有什么问题。