PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (Ray)時間3年前 (2021/01/16 16:01), 編輯推噓12(12推 0噓 49→)
留言61則, 14人參與, 3年前最新討論串5/6 (看更多)
終於有空來加入討論啦～ 這邊有 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 就是一個例子。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.227.16.212 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1610784096.A.DA8.html
推
01/16 16:10, 3年前 , 1F
sealed class真D爽
01/16 16:10, 1F
推
01/16 16:18, 3年前 , 2F
同意 Design pattern 是為了解決特定語言的缺陷
01/16 16:18, 2F
→
01/16 16:23, 3年前 , 3F
沒 syntax highlight 還是寫在部落格比較好XD
01/16 16:23, 3F
推
01/16 16:23, 3年前 , 4F
應該說語言特性可以用design pattern補救吧？
01/16 16:23, 4F
推
01/16 16:28, 3年前 , 5F
如果這個interface有三個func 原本是三個長得很像的if e
01/16 16:28, 5F
→
01/16 16:28, 3年前 , 6F
lse，變成沒有，也不會有人忘掉三個地方都要實作
01/16 16:28, 6F
→
01/16 17:21, 3年前 , 7F
alihue 最上面有 markdown 連結喔～
01/16 17:21, 7F
推
01/16 19:53, 3年前 , 8F
我認同其實只是多型取代 condition logic 唷
01/16 19:53, 8F
推
01/16 21:05, 3年前 , 9F
其實我想說... Pattern像是武學的內功心法 如果你想練
01/16 21:05, 9F
→
01/16 21:05, 3年前 , 10F
可以嘗試著不要用套件 自己寫 寫不通的時候參考別人怎麼寫
01/16 21:05, 10F
→
01/16 21:05, 3年前 , 11F
例如說可以參考Apache tomcat怎麼實作filter
01/16 21:05, 11F
→
01/16 21:05, 3年前 , 12F
或是spring怎麼建構整個架構 為什麼annotation可以有作用
01/16 21:05, 12F
→
01/16 21:05, 3年前 , 13F
每個套件裡面pattern都用超兇的 不注意思考還會以為理所當然
01/16 21:05, 13F
推
01/16 21:10, 3年前 , 14F
Ray大大必推
01/16 21:10, 14F
→
01/16 23:22, 3年前 , 15F
個人覺得什麼像內功心法之類的，都是似懂非懂才會用的
01/16 23:22, 15F
→
01/16 23:23, 3年前 , 16F
「形容詞」，而且光看別人怎麼用 pattern 大概也很容
01/16 23:23, 16F
→
01/16 23:23, 3年前 , 17F
易就學個皮毛而已
01/16 23:23, 17F
推
01/17 00:02, 3年前 , 18F
學 design pattern 的方式就是要自己試著寫框架給別人
01/17 00:02, 18F
→
01/17 00:02, 3年前 , 19F
用 框架作者及使用者雙方都不能修改對方的程式碼 而且
01/17 00:02, 19F
→
01/17 00:02, 3年前 , 20F
要有彈性能讓人插入客制化邏輯 如果常有 breaking cha
01/17 00:02, 20F
→
01/17 00:02, 3年前 , 21F
nge 沒人受得了 如果你的專案程式碼都是自己寫的 而且
01/17 00:02, 21F
→
01/17 00:02, 3年前 , 22F
習慣想改就改 那有沒有套 pattern 就不是必要的了
01/17 00:02, 22F
推
01/17 15:01, 3年前 , 23F
同意樓上
01/17 15:01, 23F
→
01/17 15:08, 3年前 , 24F
不過以型態來說所有design pattern都是oo的一些應用跟寫法
01/17 15:08, 24F
→
01/17 15:09, 3年前 , 25F
我倒是蠻想知道你所謂的策略模式長怎樣
01/17 15:09, 25F
→
01/17 17:27, 3年前 , 26F
不是所有 design pattern 都要從 OO 出發
01/17 17:27, 26F
→
01/17 17:28, 3年前 , 27F
我所謂的策略模式就是 wiki 上面寫的
01/17 17:28, 27F
→
01/17 18:08, 3年前 , 28F
看完wiki感覺你只是自以為比較懂策略模式而已
01/17 18:08, 28F
→
01/17 18:23, 3年前 , 29F
嗯，的確不是全部，只能說幾乎。context 對不太上，只能先這
01/17 18:23, 29F
→
01/17 18:23, 3年前 , 30F
樣。
01/17 18:23, 30F
→
01/17 18:58, 3年前 , 31F
yfr 你這個就 OO 本位主義啊 XD
01/17 18:58, 31F
→
01/17 19:02, 3年前 , 32F
fantasychese 你有看 wiki 範例就會知道差別。不過如果
01/17 19:02, 32F
→
01/17 19:03, 3年前 , 33F
你要說沒有違反文字描述，那照這個思路，我也可以說所
01/17 19:03, 33F
→
01/17 19:03, 3年前 , 34F
有有用到多型的都算「策略模式」:p
01/17 19:03, 34F
→
01/17 20:19, 3年前 , 35F
我大概懂你的意思了，少了一個context傳入策略的這個封裝。
01/17 20:19, 35F
→
01/17 20:23, 3年前 , 36F
的確，如果按照這個定義你說的沒錯。不過那篇文章的本意也不
01/17 20:23, 36F
→
01/17 20:23, 3年前 , 37F
在這名詞的定義就是，要完成策略模式需要再加點工
01/17 20:23, 37F
→
01/17 20:25, 3年前 , 38F
文字沒有溫度，無法表達語氣，以上討論沒有不敬的意思
01/17 20:25, 38F
→
01/17 20:27, 3年前 , 39F
可能跟我是C跟Java出身的有關，通常不太OO的語言，Design Pa
01/17 20:27, 39F
→
01/17 20:27, 3年前 , 40F
ttern我都看不太懂 （無奈
01/17 20:27, 40F
→
01/17 20:37, 3年前 , 41F
你是不是擅長函數式語言呢？
01/17 20:37, 41F
→
01/17 21:35, 3年前 , 42F
還行，FP 水很深
01/17 21:35, 42F
→
01/17 21:37, 3年前 , 43F
不過我寫這篇本來就沒有要討論策略模式，我都明寫了 :p
01/17 21:37, 43F
→
01/17 21:41, 3年前 , 44F
網路討論就是這樣，比較難抓到討論的點（笑
01/17 21:41, 44F
→
01/17 21:41, 3年前 , 45F
一個東西大家可能都有不同看法
01/17 21:41, 45F
推
01/18 22:18, 3年前 , 46F
可以先說你看的是中文還是英文wiki,原po缺的是什麼嗎？
01/18 22:18, 46F
→
01/18 22:21, 3年前 , 47F
因為你說原文不算是，只是缺少context傳入？還是更多，
01/18 22:21, 47F
→
01/18 22:21, 3年前 , 48F
這篇文章對未來讀者的價值就少了一段，建議補足
01/18 22:21, 48F
→
01/18 22:22, 3年前 , 49F
我認為兩篇文章都是懂得人在寫，兩方都省略說法，到最後
01/18 22:22, 49F
→
01/18 22:22, 3年前 , 50F
不懂的人看了還是不懂，對新手沒什麼效益
01/18 22:22, 50F
推
01/20 01:41, 3年前 , 51F
其實我在原文的底下推文連結 就有解決你說的shipperName
01/20 01:41, 51F
→
01/20 01:41, 3年前 , 52F
問題了
01/20 01:41, 52F
→
01/20 01:41, 3年前 , 53F
01/20 01:41, 53F
→
01/20 14:37, 3年前 , 54F
vi000246 你這個也是 strategy pattern 只不過用的是
01/20 14:37, 54F
→
01/20 14:38, 3年前 , 55F
generic aka type level application 去做 injection
01/20 14:38, 55F
→
01/20 14:39, 3年前 , 56F
是個滿好的方式，但還是沒有辦法避免 conversion 喔~
01/20 14:39, 56F
→
01/20 14:40, 3年前 , 57F
尤其是在轉換的時候在 c# 應該會用到 reflection
01/20 14:40, 57F
→
01/20 14:44, 3年前 , 58F
wulouise 我再強調一次，我寫這篇文沒有要討論策略模式
01/20 14:44, 58F
→
01/20 14:45, 3年前 , 59F
我想討論的是本來的 code 有什麼樣的問題以及如何重構
01/20 14:45, 59F
推
01/20 15:13, 3年前 , 60F
感覺很多人還是太聚焦在策略模式上 XD
01/20 15:13, 60F
→
01/20 15:14, 3年前 , 61F
如果一開始就學一個沒啥缺陷的語言就沒這問題
01/20 15:14, 61F
‣ 更多 electgpro 的文章
文章代碼(AID): #1W0frWse (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 electgpro 的文章
文章代碼(AID): #1W0frWse (Soft_Job)