Re: [心得]以策略模式重構switch case或if (影片)
※ 引述《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 都
必須改動 我不認為這也叫做彈性 倒不如說是防呆吧 我認
為做法應該偏向依職責需求做出拆解不同介面吧
12
終於有空來加入討論啦~ 這邊有 markdown 好讀版: 這邊我也來提一下我的看法。為了閱讀方便我把一些 code snippet 複製在這邊: ```java= public double shippingFee(String shipper, double length, double width, double3
因為有朋友想要 Python 的版本, 簡單的 legacy code 也可以讓他們玩玩 team build 練練手, 所以我就順手整理了 Python 的版本了。 - GitHub Repo & commit history: - 用 PyCharm 重構的影片,YouTube:3
上回用 Java + IntelliJ 來重構一堆 if/else 的計算運費範例, 這次改用 C# + Rider 來重構一樣的例子,方便習慣 C# 的朋友參考與練習, 不過這次刻意改用 Func<T> 來當作 strategy 的實作內容, 以 function 來取代,省去 class + interface 的部份。 兩種作法適用場景不同,東西夠小夠單純,想要少一點 class/interface 等 elements,6
恕刪 策略模式不就是一個戰鬥機器人 防禦模式就護甲值+20 攻擊模式就攻擊力+50 閃避率-10% 回復模式就自動補血+5hp18
首Po最近在客戶那邊一起 pair 重構 legacy code, 碰到了一大段 if/else statement,用來判斷什麼時候該使用哪一種cache, 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉, 可能是對 code smell 不熟,對重構不熟,對 design pattern 不熟,對工具不熟。
33
Re: [討論] Unit test 的撰寫請益先說結論,先都不要寫。 Legacy system 要先補大範圍的 integration test,確定整體的行為是對的。 如果 code 沒有要再改,不用補細部 unit tests。 原因是因為,原本 API 可能因為設計不良,導致無法寫 unit test 得先 refactor 才有辦法讓它變成 testable,這情況就要先 refactor 再補 UT16
[討論] Unit test 的撰寫請益先說我對 Unit test 的看法:測試單元(可能是 function)的邏輯是否正確 好,進入正題 小弟最近剛工作,稍微讀了一下負責的 project 的程式碼後, 要開始開發 Unit test。 現況是,各個 file (.c) dependency 很重,9
[心得] ktor 與近期 Java 相關社群活動## ktor 文章 最近參加了 kotlin 讀書會,讀完了書想說要找點東西實作。 不過,要自己寫 code 實在有點麻煩,那麼換一種方式來想, 讀懂別人的 code 也是實戰的一環! 畢竟,讀 refactoring 時,書上都會教我們要好好寫 code,4
Re: [請益] 多型用在哪ㄛ現在ㄉ想法4 沒有多型 只有介面 多型的用例之一 for(auto p_actor : actors) p_actor->act() 對ㄛ來縮 p_actor實際上到底是什麼 並不重要5
[情報] First的臺灣推特粉絲頁朋友在看完shipper 之後就迷戀上了可愛的first, 最近還為了他在推特創立了臺灣粉絲團帳號, 所以也貼來泰劇版上, 看有沒有也很喜歡可愛(但超高的)first的同好, 推特帳號如下:3
Re: [討論] 請大家聊聊靜態語言的缺點借題發揮一下:static typed for the win 不過還是先切題回答「靜態語言的缺點」: 在大部分常用的靜態語言中,的確可能出現 valid program 不好標注 type 的情況 不過到底有多難標注就完全看是哪個語言跟哪個版本了 ------ 這些都太嫩了 真的要讓他看不懂,要他死 最簡單的方式就是讓物件中含有大量的隱含狀態 讓每個 function call 的結果都跟上下文有關 不要用什麼全域變數來做隱含狀態