1
Java 代码 switch 分支过多，怎么改写比较优雅呢？
source link: https://www.v2ex.com/t/911506
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
一个收到消息，分发给不同的处理方法的代码
消息类型已经有十几种了
使用 switch 来根据消息类型跳转不同的处理方法
这个 switch 看起来就很庞大了
请教一下，有没有很好的方式来重构这种情况的代码呢
23 条回复 • 2023-01-30 10:53:34 +08:00
 |
7911364440 1 小时 22 分钟前 策略模式啊
|
 |
dddd1919 1 小时 20 分钟前 典型的工厂模式
|
 |
yaodao 1 小时 18 分钟前 via iPhone 如果 switch 中的内容比较简单，可以使用枚举类实现抽象方法的简单策略模式。如果比较复杂可以使用监听者模式，广播消息，但每个监听者只处理自己相应的消息。
|
 |
TWorldIsNButThis 1 小时 17 分钟前 via iPhone 使用语言内建的 dispatch 功能
也就是子类型多态 |
 |
ql562482472 1 小时 14 分钟前 switch 都写不优雅 你到底写成啥样了 发出来看看吧
|
 |
ashong 1 小时 1 分钟前 via iPhone handlers[event].action()
|
1 |
xiangagou 1 小时 1 分钟前 最通用的就是工厂+策略模式修改,几乎不用动脑子,其他模式得看业务匹配情况
|
 |
nothingistrue 57 分钟前 十几种还不算多，如果能做成枚举的话，switch 枚举并无不妥。如果太多做不成枚举，或者稍微有那么一两个变异的分支，用 if else 也不丢人。你要知道，你后面的处理是分发不同方法，那么就算有 50 个，代码行也就 150 行，不多。
这里的重点，还是你的消息类型的命名规则。消息类型如果是依次罗列命名，超过 10 个就麻烦，超过 20 个就没法用了。基本上，超过 20 个类型，就该考虑对消息类型的名称进行归纳分级。如果消息类型有良好的命名规则，消息分发可能就不需要 swtich 、if else 了，十几行代码就能搞定。 |
 |
fredli 54 分钟前 抽象类继承，消息子类，多态
|
 |
zhady009 52 分钟前 每个消息类型对应一个 ActionChain, Action 对应具体的业务
关于消息类型和 ActionChain 的关系建立可以是硬编码, 也可以用 Spring 的 BeanPostProcessor+注解的方式 |
 |
lysS 43 分钟前 信息类型是确定的，可以用数组
|
 |
lyusantu 25 分钟前 保持 switch 写法
写完后折叠 switch 看起来就比较优雅了 |
 |
ianEros 23 分钟前 复杂一点写策略，简单逻辑表驱动
|
 |
NoKey 20 分钟前 @ql562482472 就是 switch 下面十几个 case ，可能还会增长，到一定时候，肯定不好看，一大片的 case😂
|
 |
lambdAlan 18 分钟前 策略模式加工厂模式即可
|
|
ianEros 16 分钟前 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); |
 |
libook 8 分钟前 除非消息类型划分不合理，或者重复处理逻辑太多，否则不认为 switch 分枝多有什么问题。
|
 |
PiersSoCool 4 分钟前 |
 |
cubecube 4 分钟前 大规模用策略模式的时候，代码给别人看的时候容易一坨屎，尤其是还是那种 switch 不稳定，状态可能相互有关联的时候。。。
我个人倾向于不改 switch ，处理逻辑复杂的话，内容包在一个函数里面得了 |
 |
playtomandjerry 3 分钟前 不要整花里胡哨的优化，妈的，自己过段时间都看起来费劲，后面人接手能头疼死。switch 内不要放逻辑，直接抽方法出去，已经是很清晰的写法了，简单明了
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK