※ 引述《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 有提供更好的預先除錯功能而已。

code 跟 design 跟 language 當然有關係尤其是原原 po 後來也有拿其他語言出來拿 kotlin 出來不為過吧？BTW 我沒有說 interface 有什麼問題，我只有說那不是策略模式而已至於你說的「彈性」我覺得 ok，只是在這邊沒必要

如果說因為改動interface 導至全部的implement class 都必須改動 我不認為這也叫做彈性 倒不如說是防呆吧 我認為做法應該偏向依職責需求做出拆解不同介面吧