終於有空來加入討論啦～
這邊有 markdown 好讀版：https://hackmd.io/@rayshih/SyAAwbxkd
這邊我也來提一下我的看法。為了閱讀方便我把一些 code snippet 複製在這邊：
```java=
public double shippingFee(String shipper, double length, double width, double
height, double weight) {
if (shipper.equals("black cat")) {
return // some calculation
} else if (shipper.equals("hsinchu")) {
return // some calculation
} else if (shipper.equals("post office")) {
return // some calculation
} else {
throw new IllegalArgumentException("shipper not exist");
}
}
```
然後以下是 refactor 過後的程式碼片段：
首先你訂了個 interface
```java=
public interface Shipper {
double calculateFee(Product product);
}
```
然後所有 shipper 都會實作這個 interface：
```java=
public class BlackCat implements Shipper {
public BlackCat() {
}
@Override
public double calculateFee(Product product) {
return // some calculation
}
}
```
於是本來的 function shippingFee 被 refactor 成這樣：
```java=
public class Cart {
private final HashMap<String, Shipper> shippers = new HashMap<>() {{
put("black cat", new BlackCat());
put("hsinchu", new Hsinchu());
put("post office", new PostOffice());
}};
public double shippingFee(String shipperName, Product product) {
if (shippers.containsKey(shipperName)) {
return shippers.get(shipperName).calculateFee(product);
}
throw new IllegalArgumentException("shipper not exist");
}
}
```
首先，這根本不能算「策略模式」，只能算是一般的多型應用，不過我這邊不是很想討
論 strategy pattern 本身，有興趣的可以去 wiki 比較一下差在哪裡。
## 所以原本的 code 到底有什麼問題？
基本上有兩點可以討論：
1. 不同計算方法都被寫在同一個 function 裡
2. 如果 caller 丟了一個不認識的 shipperName，這 function 就會丟出 exception
### 1. 不同計算方法都被寫在同一個 function 裡
原 solution 定義了一個 interface，所以要實作這個 function 必須建立一個 class
來實作這個 interface，所以算是有解決到這個問題。但其實單純的為不同的 shipper
建立相對應的 function 就行了，並沒有必要多一個 interface：
```java=
private double blackCatShippingFee(Product product) {
return // The calculation for black cat
}
// hsinchuShippingFee and postOfficeShippingFee are similar
public double shippingFee(String shipper, Product product) {
if (shipper.equals("black cat")) {
return this.blackCatShippingFee(product);
} else if (shipper.equals("hsinchu")) {
return this.hsinchuShippingFee(product);
} else if (shipper.equals("post office")) {
return this.postOfficeShippingFee(product);
} else {
throw new IllegalArgumentException("shipper not exist");
}
}
```
### 2. 如果 caller 丟了一個不認識的 shipperName，這 function 就會丟出
exception
假設今天，我們新增了一個貨運商，工程師記得要建立一個新的 class 並實作 Shipper
interface，但是他忘了把它加入 shippers hashmap，又剛好沒寫測試，於是 rollout
之後就觸發了 exception，就 QQ 惹。
有沒有方法可以保證不會有例外呢？這問題就有點有趣了，但首先讓我們先換一個語言
kotlin：
```kotlin=
sealed class Shipper {
object BlackCat: Shipper()
object Hsinchu: Shipper()
object PostOffice: Shipper()
}
data class Product(
val length: Double,
val height: Double,
val weight: Double,
)
fun shippingFee(shipper: Shipper, product: Product): Double {
return when(shipper) {
is Shipper.BlackCat -> {
// computation here
}
is Shipper.Hsinchu -> {
// computation here
}
is Shipper.PostOffice -> {
// computation here
}
}
}
fun main(args: Array<String>) {
val product = Product(7.0, 8.0, 9.0)
println(shippingFee(Shipper.BlackCat, product))
}
```
因為 kotlin 的 when 有提供 exhausive check 的功能。只要使用 sealed class，
compiler 就會幫你檢查你有沒有漏掉的 case。所以假設我們新增一個新的 case 像這樣
：
```kotlin=
sealed class Shipper {
object BlackCat: Shipper()
object Hsinchu: Shipper()
object PostOffice: Shipper()
object Lalamove: Shipper() // 新增的部分
}
```
Compiler 會直接吐一個 error 給你：
```
main.kt:15:10: error: 'when' expression must be exhaustive, add necessary
'Lalamove' branch or 'else' branch instead
return when(shipper) {
```
這時，工程師就可以根據 compiler 的提醒來做相對應的修正。
所以其實可以去掉 exception, or can't I?
## 如果 Shipper 是由 user 輸入的資料決定的呢？
因為這邊 Shipper 是自定義的 data type，所以需要有個過程把 user input 轉換成這
些 data type
```kotlin=
val userInput = // some function return user input
val shipper = when (userInput) {
'black cat' -> Shipper.BlackCat
'hsinchu' -> Shipper.Hsinchu
'post office' -> Shipper.PostOffice
else -> throw IllegalArgumentException('shipper not exist')
}
println(shippingFee(shipper, product))
```
只有在 shipper 事先定義好的情況下才能去掉 exception，所以如果 shipper 是由
user input 決定的話，就還是會有 user 輸入沒有合作的貨運商的狀況，這個時候還是
需要 throw exception 才行。
這時，你可能會問，既然還是要 throw exception，那有差嗎？有的。
## 差別在於：例外是從哪裡、何時丟出來的
想像一下如果你的 shippingFee 是在整個 callstack 裡面的第十層，也就是
shipperName 就這樣一路的被傳了十層。一旦 exception 出現，你也要花不少時間去
trace code 才會知道這個 shipperName 是在什麼情況下變成不支援的 value。
相較之下，因為上面提到的 conversion from user input to Shipper data type 本身
就是一個檢查的過程，所以如果我們在 user input 之後馬上做 conversion，那萬一出
現了 exception，我們也可以很快地知道到底是從哪裡開始錯的。
## Boundary between Safe and Unsafe
這個架構基本上可以被視為兩個部分
1. conversion and check
2. execution
而其中因為 exhausive check 的關係，第二部分可以說是 safe 的，相較之下第一部分
就是 unsafe。也就是我們可以通過這個手法把系統切割成 safe 跟 unsafe。我們可以
對 unsafe 的部分做更完整的測試。safe 的部分就可以相對放心。
當然，你也可以把 fee computation 放進 shipper 並封裝成一個 interface/function
，不過我覺得這相對來說比較不重要，有興趣的可以自己查查資料看要怎麼做。
可惜的是 Java 並沒有這樣的設計，所以如果使用的是 Java，有很大的機率你還是需要
各種 throw new Exception。
## 結語
雖然現在 Design Pattern 看起來是個顯學，不過在使用 Design Pattern 之前，要先能
夠先了解問題本身的性質，再去看看使否有模式可以解決，不然很容易會變成為套而套，
而所謂的 refactor 也不一定能帶來什麼實質的效用。
另外，有一些人會倡導 Design Pattern 是 language agnostic，其實並不盡然，這篇使
用 kotlin 的 sealed class 就是一個例子。