最近在客户那边一起 pair 重构 legacy code，
碰到了一大段 if/else statement，用来判断什么时候该使用哪一种cache，
并依照不同 cache 的逻辑来决定回传的内容。
发现还是有蛮多风气比较封闭的公司对这类型的基本功跟处理不是很熟悉，
可能是对 code smell 不熟，对重构不熟，对 design pattern 不熟，对工具不熟。
因此，我用自己几年前的一个“计算运费”的范例，设计成这类型程式码重构的简介。
这个范例之前是 C#，这次示范我改用 Java，用 IntelliJ 来重构。
有整个重构过程的 IDE 操作影片，也有每一个重构 baby steps 的 commit history。
影片：https://youtu.be/zO-NnNC-xyg
GitHub commit history: https://bit.ly/strategy-91
也可以参考 《Refactoring to Patterns》 的
Replace Conditional Logic with Strategy：
https://www.informit.com/articles/article.aspx?p=1398607&seqNum=2
IntelliJ/Android Studio 在重构上还是地表上最强的兵器啊。

推91哥

实用推Y

91安安

推，legacy code看到if又case又if真的吐血

shipper输入的部分还有改善的空间吗？感觉用字串很容易出包...

包成 enum 吧，然后在 convert 到 enum 时做 err handling

楼上,我想问一下当如果enum没该对应,怎么处理比较好?

Throw exception.

噗 XDDD

推~

改用kotlin重构,你会看到新世界

这样switch的default动作用exception有点不太妥吧?我会这样问是我曾经是在对应后,外面增加判断是否null想知道有没有其他方式,处理对应不到的情况

重点应该是对应不到后的行为，如果这本身就是不合法的操作，你在外面检查到 null 之后，还是要丢 exception 啊。

还是看当下商业逻辑，如果走不下去直接丢 ex 外面就不用检查 null 更干净

switch的defalut动作是合法的阿<=这边在于讨论改成enum情况

推～

你应该不会想要全部用到的地方都检查 null，把责任丢给convertor ，错就丢 ex，如此一来其他地方直接用 enum 就干净很多

我知道你的使用情况了,我的情况是要吐不同的ex才多判断null

对 还是根据你的情节决定 default 干什么事，说不定你们有default enum

怕null做个空物件

推~ 影片看不是很明白但git history很清楚

推 看history很明确 每个步骤

https://dotnetfiddle.net/L2BGVY写了一个用泛型的范例

谢谢楼上几位的鼓励，我培训中的练习题都是这样呈现的

吃太饱

enum class Shipper implement Product interface override caculateFee method.另外 Shipper constuctor宣告 shipperName 属性 强迫每个 enum 一定有 name属性 再把 Cart 的 hashmap 替换成 Shipper.shippingFee(input) static method 里面用 values() 比对 name找出对应的 enum 再呼叫 caculateFee 即可这样就没有 if 也没有 map 也没有 Cart class

你这个应该不能叫做策略模式，因为没有动态 injection另外我满好奇你觉得的 code smell 是指什么在我看来你的 refactor 只有把 if 取代成 map除此以外结构上并没有什么太大的差异

data clump 变成 parameter object: Product顺带一提，欢迎大家把自己的想法、重构、设计呈现出来soure code 在 github 上，连 branch 都开好了欢迎fork回去，自己录一版重构的影片跟repo放上来讨论soure -> source

if 的确很难维护啊，光是改成switch 就有部分防呆效果了。