Re: [心得]以策略模式重構switch case或if (影片)

[steven11329 (清新柳橙)]

※ 引述《electgpro (Ray)》之銘言：
: 首先，這根本不能算「策略模式」，只能算是一般的多型應用，不過我這邊不是很想討
: 論 strategy pattern 本身，有興趣的可以去 wiki 比較一下差在哪裡。
: ## 所以原本的 code 到底有什麼問題？
: 基本上有兩點可以討論：
: 1. 不同計算方法都被寫在同一個 function 裡
: 2. 如果 caller 丟了一個不認識的 shipperName，這 function 就會丟出 exception
: ### 1. 不同計算方法都被寫在同一個 function 裡
: 原 solution 定義了一個 interface，所以要實作這個 function 必須建立一個 class
: 來實作這個 interface，所以算是有解決到這個問題。但其實單純的為不同的 shipper
: 建立相對應的 function 就行了，並沒有必要多一個 interface：

原原 PO 用 interface 的好處是，shipper 有新的行為時。
可以很簡單的在 interface 加新的 function。
同時可以檢查有 implement Shipper 的 class 要加入新的 function。
感覺上，彈性更好。

缺點嘛... 如果 shipper 很多時每個都要再補 function 是比較累一點。

: ### 2. 如果 caller 丟了一個不認識的 shipperName，這 function 就會丟出
: exception
: 假設今天，我們新增了一個貨運商，工程師記得要建立一個新的 class 並實作 Shipper
: interface，但是他忘了把它加入 shippers hashmap，又剛好沒寫測試，於是 rollout
: 之後就觸發了 exception，就 QQ 惹。
: 有沒有方法可以保證不會有例外呢？這問題就有點有趣了，但首先讓我們先換一個語言

以下略...

: 因為 kotlin 的 when 有提供 exhausive check 的功能。 (以下略...
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

你都說了是 kotlin 功能了，這已經跟 code 的 design 無關了吧...
只能說用 kotlin 有提供更好的預先除錯功能而已。

--
人生宗旨：摔不死！那就再來吧！

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.169.245.81 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1611124959.A.D93.html
※ 編輯: steven11329 (118.169.245.81 臺灣), 01/20/2021 14:44:50
→ electgpro: code 跟 design 跟 language 當然有關係
→ electgpro: 尤其是原原 po 後來也有拿其他語言出來
→ electgpro: 拿 kotlin 出來不為過吧？
→ electgpro: BTW 我沒有說 interface 有什麼問題，我只有說那不是
→ electgpro: 策略模式而已
→ electgpro: 至於你說的「彈性」我覺得 ok，只是在這邊沒必要
推 ura1210: 如果說因為改動interface 導至全部的implement class 都
→ ura1210: 必須改動 我不認為這也叫做彈性 倒不如說是防呆吧 我認
→ ura1210: 為做法應該偏向依職責需求做出拆解不同介面吧