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