看板 Soft_Job
拿策略模式舉例,因為正好在研究這個 http://i.imgur.com/UWc8gR6.jpg
Context 和 Strategy:組合關係,Context 持有 Strategy。 Strategy 和 ConcreteStrategyA/B:實現關係,ConcreteStrategyA 和 ConcreteStrategy 先簡單定義,策略模式是"將相同類型可互相替換的操作封裝成獨立策略,達到在運行時動態替換"的一種設計模式 Java要實現的話,比較普遍的作法: 1. 定義策略Class or Interface 2. 實現具體策略類 3. 創建上下文類管理策略的設定與使用 但是使用一些天生自帶FP特性的語言(現在用Kotlin 發現策略模式好像根本不需要 最簡單的方法是直接利用高階函數,把需要的操作當參數傳進去用 連定義Interface都省了,只要函數簽名相同都行 如果要限制操作種類 只要寫個枚舉類整理一下全部的操作就好,也不用額外的策略類跟上下文 還能隱藏策略的具體實現只讓選擇本身可見 看了看,好像策略模式用不太到? 是不是高階函數太好用了 只要關於動態行為的時候 用高階函數加個函數參數搞定 FP是不是某種程度上殺死設計模式了? ----- Sent from JPTT on my Google Pixel 7 Pro. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.136.159.79 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1719284536.A.657.html ※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:05:01 ※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:06:15
sw12: 設計模式,是從OO長出來的.... 06/25 11:12
sw12: 跟殺死沒關係。就不適用 06/25 11:12
※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:14:51
NDark: OO就跟Scrum是一種理所當然 專注在他們想解決的課題才合理 06/25 11:14
papa510: 是的 很多情境下可以設計更簡單,傳參數就好了 06/25 11:53
Kroner: 精胺酸什麼時候吃 06/25 18:41
w0005151: 你的例子還是策略模式啊,只是interface省了而已 06/25 13:22
w0005151: FP不是只是first call function就是FP 06/25 13:22
w0005151: *first class function 06/25 13:23
Kroner: 兒童魚油推薦 06/25 19:16
brucetu: 那你不就只有殺死策略模式-.- 舉個例子 singleton 呢?觀 06/25 13:52
brucetu: 察者 / 裝飾器 / 發布訂閱等等常用的模式呢?你把這些拿 06/25 13:52
brucetu: 出來看再看看 FP 再學一下 javascript 這種超高自由度的 06/25 13:52
Chricey: 瑪卡功效女性 06/25 19:20
brucetu: 語言,再重新下結論不遲 06/25 13:52
brucetu: 即使是 JS 也會用到各種設計模式 06/25 13:53
brucetu: 高內聚低耦合可測試才是重點,OO或FP不重要也可以混用 06/25 14:00
Kroner: 苦瓜胜肽副作用 06/25 20:50
wei115: 設計模式也要看語言八 有些設計模式是在補語法的問題 06/25 14:37
wei115: 有語言特性支援,很多技巧可以省略 06/25 14:38
MoonCode: 還要配上好的型別系統才能用的爽 06/25 14:39
Kroner: 鋅的功效 06/25 21:56
black2575: 殺死Pattern 不是好事嗎 如果今天語言能解決對應問題 06/25 15:30
black2575: 我不就不需要另外尻這些Pattern了 06/25 15:30
Lordaeron: 台灣的另一個有趣的現象,就是大家的案子,基本上沒幾 06/25 15:50
Chricey: uc2是什麼 06/25 23:32
Lordaeron: 個"物件"會重用的,但大家就是天天design pattern. 06/25 15:50
NDark: 那就是overdesign 06/25 16:05
NDark: 但也跟案子的型態很有關 06/25 16:06
Kroner: 魚油什麼人不能吃 06/25 23:40
NDark: 週期太短 產品風險太高無法迴避的 線上正常的 要減少重構 06/25 16:06
NDark: 新code可以用更好的方法去實現 但不要回頭為了重用而重改 06/25 16:07
NDark: 換言之 不是重構程式碼 而是重構人的思維模式 06/25 16:07
Kroner: 葉黃素 06/26 00:07
mercurycgt68: 前公司架構師:我入行這幾年 06/25 16:49
mercurycgt68: 從來不需要用什麼design pattern 06/25 16:49
NDark: 不用的原因有可能已經是無招勝有招 06/25 16:50
Kroner: 益生菌 06/26 00:31
NDark: 因為對工作於設計模式出現之前的也是會有方法解決問題 06/25 16:51
NDark: 設計模式只是把那些方法歸類取名 06/25 16:51
NDark: 所以 不用 指得不是不用方法 而是那時還不叫設計模式 06/25 16:51
Chricey: d3 06/26 00:32
abccbaandy: 推19F,一堆整個開發週期都只有一個impl的在那邊定 06/25 16:53
abccbaandy: interface超87,不定還會森77說你開發習慣不好XD 06/25 16:53
NDark: 這就是overdesign 沒有擴充需求應是搞需求出來 06/25 16:57
Kroner: 黑瑪卡推薦 06/26 00:35
NDark: 設計是為了需求服務 這點很多人沒搞懂 06/25 16:57
NDark: 在需求很不明確或是可以預期跳躍的時候 要盡量少系統與架構 06/25 16:58
k798976869: FP就是一種可以一直串的設計模式啊 要盡量寫pure func 06/25 18:41
Kroner: 益生菌 06/25 18:41
k798976869: tion 06/25 18:41
wulouise: 原來fp是說functional programming.. DP就是有需要才用 06/25 18:47
recorriendo: 你說的模式本身就可以當作是FP和OOP的結合 06/25 19:16
Chricey: 維他命d的功效 06/25 19:16
recorriendo: 基本的OOP 每個物件就可以視為帶有一組"背景資料" 06/25 19:18
recorriendo: 但方法函式不能"動態擴充" 06/25 19:18
recorriendo: 而純FP則是沒有context的概念 你的模式等於把兩方 06/25 19:20
Chricey: 葉黃素功效 06/25 19:20
recorriendo: 加上各自缺少的部分 06/25 19:20
recorriendo: 有沒有必要當然是取決於現實需求 06/25 19:21
KY1998: 你應該多看原始碼,其實用不少,你同事會不會又是另一回事 06/25 20:50
Kroner: b群推薦 06/25 20:50
blackdiz: 這支影片的觀點滿類似的,可以參考看看 06/25 21:29
blackdiz: https://youtu.be/srQt1NAHYC0 06/25 21:29
foxbrush: *定義Interface都省了,只要函數簽名相同都行* <= 你自 06/25 21:56
Kroner: 魚油什麼時候吃 06/25 21:56
foxbrush: 己都說了函數簽名仍要相同,不過是語言特性省去寫Interf 06/25 21:56
foxbrush: ace,還是一樣的pattern 06/25 21:56
superpandal: 設計模式就是oop如Java 因為語言限制而產生的經驗法 06/25 23:32
Chricey: 蔓越莓不能和什麼一起吃 06/25 23:32
superpandal: 則 即便你不知道什麼叫作策略模式 你依照限制依究能 06/25 23:34
superpandal: 產生出來而不用看書 只有這類的語言才講究這種東西 06/25 23:36
superpandal: fp或動態語言很爽的其實可以不用管這種東西 而程式碼 06/25 23:40
Kroner: 苦瓜胜肽 06/25 23:40
superpandal: 品質最終還是取決於個人的心態和目的 06/25 23:41
superpandal: 記得在對岸論壇看過某句話很有道理 忘記在哪 大概意 06/26 00:05
superpandal: 思是人們發明新概念與觀點方式用來解決問題 然而該事 06/26 00:07
Kroner: b群 06/26 00:07
superpandal: 物會用某種型式反過來束縛你 06/26 00:08
superpandal: 不過意思差不多可以類比成獨孤九劍和一般劍法 06/26 00:10
vi000246: 看情況吧 如果你是要寫一個plugin給別人用 定interface 06/26 00:31
Chricey: UC2 06/26 00:31
vi000246: 就滿重要的 就好像電線之於插座 用電線可以接上任何電 06/26 00:32
vi000246: 器 但要是220v接到100v呢 這時就需要靠interface來限定 06/26 00:32
vi000246: 接口長怎樣 06/26 00:32
Kroner: 鋅功效女性 06/26 00:32
vi000246: 這世界的電器百百種 有個既成的規格可以讓電器開發商 06/26 00:34
vi000246: 不需煩惱接口的事 當然小專案就不需要考慮這些了 06/26 00:35
vi000246: 能動比較重要 06/26 00:35
Kroner: GABA 06/26 00:35
abccbaandy: 樓上這種教科書般的例子實際很少有吧,真要說手機快充 06/26 00:49
abccbaandy: 不也搞了一堆特規... 06/26 00:49
DrTech: 台灣沒什麼人在寫十萬行起跳的程式碼framework,不用開發f 06/26 02:16
DrTech: ramework給百人,千人,萬人用。當然覺得不需要設計模式。 06/26 02:16
DrTech: 你寫的程式頂多幾千行,頂多2-3個人會看第二次,就很了不 06/26 02:16
DrTech: 起了。當然不需要設計模式也能做得更好。 06/26 02:16
DrTech: 設計模式的聖經書書名都說了:Elements of Reusable Objec 06/26 02:21
DrTech: t-Oriented Software 06/26 02:21
DrTech: 因為你寫的,不需要一直給別人重複使用,當然不需要設計模 06/26 02:22
DrTech: 式。 06/26 02:22
brucetu: 讓我用綠豆糕的角度回答這個問題,我覺得設計模式是許多 06/26 08:28
brucetu: 種可用來描述演算法的常用模式,一個問題可以有多種不同 06/26 08:28
brucetu: 的解,你的解題思路不同就會選用不同的模式,倒不一定是 06/26 08:28
brucetu: 為了重用程式碼。就像一個問題可以迴圈解也可以遞迴解, 06/26 08:28
brucetu: 也還可以用狀態機解。套用模式的好處是別人容易看懂你在 06/26 08:29
brucetu: 做什麼 06/26 08:29
recorriendo: 沒有完美的語言 模式也只是前人在補強功能的各種方 06/26 08:36
recorriendo: 式中歸納出來供人借鑒的 06/26 08:36
recorriendo: 這些被歸納出來的模式 就是有經過時間證明其價值 06/26 08:36
recorriendo: 要不照模式 當然可以 不過多數時候是幾個月後就會 06/26 08:36
recorriendo: 後悔當初自以為的天才hack 06/26 08:36
superpandal: 十萬行的多數是屎山 最少行數最簡短的實現一樣的功能 06/26 09:25
superpandal: 才是好的 物件導向也只是其中一種方式 06/26 09:27
superpandal: 這就是套路或者稱作是定石摟 然而並不需要專門去學才 06/26 09:32
superpandal: 會了解 如上所說 這只是限制下的經驗 看了這篇說實話 06/26 09:33
WTS2accuracy: 什麼鬼邏輯...FP只是換個方式實作設計模式而已 06/26 09:34
superpandal: 我也不知道什麼叫作策略模式 但我就寫出一模一樣的東 06/26 09:34
superpandal: 西過 06/26 09:34
superpandal: 要看語言本身特性 對很多語言來講是可以跳過這環節的 06/26 09:36
zxcasdjason1: 個人淺見是,設計模式像心法,OO, FP 則像外功。FP 06/26 11:38
zxcasdjason1: 是否好用,還是要看你用的語言特性,像原po提到的J 06/26 11:38
zxcasdjason1: S, class 只是語法糖,跟 java, c#, 本質就不同, 06/26 11:38
zxcasdjason1: 對 JS 來說,用 function 更直覺。 自己工作上從 O 06/26 11:38
zxcasdjason1: O 轉 FP 一段時間, 相比 OO 來說,FP 設計上講究 06/26 11:38
zxcasdjason1: 狀態皆來自參數,無副作用的函式測試好寫,也好維 06/26 11:38
zxcasdjason1: 護。 06/26 11:38
wulouise: 咦原來十萬就是很多了... 06/26 12:54
ma721: 自己跟別人看好懂好維護就行 06/26 14:01
KY1998: JS轉TS時,generics應該會讓你不太爽 06/26 14:19
superpandal: 實際上設計模式還是外功 你整的再好也只是在上面玩耍 06/26 15:46
superpandal: 能整到十萬我懷疑它的品質以及可維護程式可控性 06/26 15:49
angusyu: 怎麼可能取代策略模式…我一樣用策略模式不會塞lambda 06/26 20:30
Lipraxde: 寫十萬行 code... 有兩種,一種是需要寫十萬行...另一 06/26 20:36
Lipraxde: 種是寫了十萬行,就像 design pattern 一樣,一種是需 06/26 20:36
Lipraxde: 要用...另一種是用下去了 06/26 20:36
viper9709: 台灣的軟體生命週期太短+1 06/26 21:19
peter98: design pattern常用的可以用,不常用的就別用,很多desig 06/26 22:55
peter98: n pattern寫到最後會讓人無法trace code,如果只是個幾萬 06/26 22:56
peter98: 行而已的專案就別全部硬要套design pattern了,常用的倒 06/26 22:56
peter98: 是可以用,比如builder/factory/singleton/deco等 06/26 22:56
peter98: 另外台灣的軟體不是軟體,板子換了軟體重寫,也不需要用 06/26 22:57
peter98: design pattern,寫code可以hardcode就好,速度快,出錯 06/26 22:58
peter98: 也沒關係,反正出bug的時候,該軟體可能都快結束生命了 06/26 22:58
peter98: 反正出問題也不需要再修~ 何必搞design pattern? 06/26 22:58
appleway: 不同的語言有不同的DP. Haskell有lens 但是Java不用 06/26 23:24
CoNsTaR: FP 以外唯一支持 C++ TMP,C++20/23 加上 boost::mp11 06/27 01:34
CoNsTaR: 根本 compile-time dependent type,幾乎是想做什麼都可 06/27 01:34
CoNsTaR: 以幫你 type check 06/27 01:34
CoNsTaR: 傳統設計模式相較之下就像是二維平面的小孩玩具一樣幫 QQ 06/27 01:34
Suleika: interface寫好,設計想得很好,結果同類型新專案不拿去 06/27 17:10
Suleika: 共用的場景太多了,寫的讓同事看得懂優先級可能高點 06/27 17:10
ko27tye: 選擇用什麼pattern之前 先考慮同事的程度吧 06/27 19:23
Lipraxde: Builder 跟 factory 不是很讓人喜歡...看到生搬硬套的 06/27 20:28
Lipraxde: 用法就很討厭 06/27 20:28
jhjhs33504: 不需要幫印度人歸納的方法背書很多模式在OS,APP能找到 06/29 10:00
legion87: 了解每個pattern的精神就好,很多程式碼的語法精進的本 07/06 17:14
legion87: 身就已經包含了一些設計模式的概念了 07/06 17:14
legion87: 不是說一定要套用最原本的class diagram才叫設計模式 07/06 17:15
legion87: Java的enum一出來,策略模式的寫法都改變了,但精神上還 07/06 17:16
legion87: 是策略模式 07/06 17:16
dickgg: 其實 FP 歷史是早於 OO 的,只是後來OO 比較紅。比較像是 07/09 23:42
dickgg: 純的 FP 不好懂所以流行 OO + DP 07/09 23:42