switch太多的代码是否可以优化得更优雅一点？

Creator 2.x
#20

回答楼主，经典的可以用多态来解决的问题。
声明一个统一的操作方法，子类负责实现

#21

我这叫机器人……你是不是对 AI 的期待值太高了，能回复这么复杂的内容

#22

首先按照截图来看，已经有几十个case，已经不属于简单逻辑了。其次封装并不是为了节省代码量，而是为了结构更清晰，但看这个代码，分支肯定会向后扩充，已有的逻辑也会调整，这样就是会给其他维护的人带来心智负担。现在从截图看并不能确定已经到达了怎样的一个复杂度，case后面可能简单 return 了一个值，也可能是调用了一个方法，也可能这本身就是一个工厂方法，但无论如何，不应该让这个分支膨胀下去了，用策略模式优化分支条件是一个不错的方向。

#23

哈哈哈O(∩_∩)O哈哈~

#24

我举个例子：假如这个分支是判断玩家的道具卡是哪个，从而采用不同的道具卡方法，如果按照策略方法，岂不是100多个道具卡就要新建100多个类？很明显不可能的。策略模式只适合10个左右的case，并不适合过多的这种50到100个case的情况

1赞
#25

首先，你都100多种分支条件了，你还用swtich？其次在ts里并不需要建100个类，简单的你可以使用函数对象，复杂的可以用 接口 + 匿名对象

#26 
itemUseExtensions: { [key: ItemType]: (itemData: ItemData, cnt: number) => void } = {}

itemUseExtensions[ItemType.A] = fucntion(itemData: ItemData, cnt: number) {
    // do someting
}

function useItem(itemId: number, cnt: number) {
    const itemData = itemSo[itemId]
    const useFunc = itemUseExtensions[itemData.type]
    if (useFunc) {
        useFunc(itemData , cnt);
    }
    else {
         // default behavior
    }
    // other behavior
}
#27

我明白你的意思，但是这个是理想条件下。采用map来索引这些函数，但是，这种条件下先不说拿空间换时间，我们来说下复杂点的情况是:每个道具卡可能都需要传递不一样的参数，也就是函数参数是不规则的，这种情况下如果传递一个数组过去，然后不同的函数取到的参数不一样，这样其实就是去除了函数参数的类型，相当于无类型了，跟switch的情况相比，你觉得哪个好维护点？switch只是长点，难看罢了。
还有更复杂的情况是:假如switch case后还需要根据不同的道具卡函数执行后的返回值来进行判断，最重要的是返回值也是不规则的。。。所以你懂的，哪有什么万能的模式，只有万能的switch

#28

你描述的情况就更应该使用策略模式而不是是分支条件，你把复杂度统统控制在了一个函数里，一个函数一百上千行，这个函数还能维护吗。每个特殊条件理应只关注自己所需关注的情景，取参你在扩展函数里取不行吗，难道你要在swtich最开始把所有参数的情况都罗列出来？还有你说的后处理，返回值应该也应该有其标记，再做一次策略不就行了？

#29

越复杂的逻辑分支越值得使用策略。

#30

我觉得难，不适用，因为我的函数确实用不了策略模式，具体说起来比我上面的复杂几百倍，一言两语没法说清，有空我可以试着去套用一下这个模式，但是难度比较大，重构起来，目前还不清楚是否适用

#31

啊对对对 :100:

#32

@jare ，这种该封号的不封，不该封号的却封一堆，能不能做点正经事？

1赞
#33

请问这种情况下您是怎样调用这个包含switch的方法的呢

#34

直接调用啊~比如主人公走到一个npc面前，switch判断npc（大概有50种）的类型，然后根据不同的npc返回不同的参数，然后根据这些参数来决定发送回去前端的数据是哪些，如果用策略模式，发送消息的语句就要包含到每一个npc种类的策略函数中去，但是这些npc的处理逻辑不能包含这些发送消息的语句，因为npc的处理逻辑不只是在包含switch的语句中被使用到，还有几个地方被使用到，而这些地方发送消息的逻辑是不能包含在里面的，等等之类的，我这里只是举个例子，抛砖引玉
下面这句不是回复你的哈，回复给其他一些人：
如果不想讨论可以正常回复，没必要使用对对对之类的词语，让人恶心真的
你们没遇到过，不代表模式就是万能的，只是你们没遇到而已

#35

试试分层状态机或者行为树

#36

分支逻辑简单到只有一两行代码，可以继续switch，否则考虑 map配置+class了

#37

可以写成对象的结构，就是表结构，就不用写switch case了

#38

策略模式确实优秀，把处理的逻辑放到单独的类里面可以通过类的继承自然地分了层

#39

策略越复杂就越不通用，需求拓展起来也麻烦。
简单的事情别搞复杂了，好的方法都是简单的。
写到json里增删改查方便，可读性强，拓展性强，就是最优解。