作者ohmylove347 (米特巴爾)
看板Soft_Job
標題[討論] FP正在殺死設計模式嗎？
時間Tue Jun 25 11:02:11 2024
拿策略模式舉例，因為正好在研究這個
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://webptt.com/m.aspx?n=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
1F：推 sw12: 設計模式，是從OO長出來的.... 06/25 11:12
2F：→ sw12: 跟殺死沒關係。就不適用 06/25 11:12
※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:14:51
3F：→ NDark: OO就跟Scrum是一種理所當然 專注在他們想解決的課題才合理 06/25 11:14
4F：推 papa510: 是的 很多情境下可以設計更簡單，傳參數就好了 06/25 11:53
5F：→ w0005151: 你的例子還是策略模式啊，只是interface省了而已 06/25 13:22
6F：→ w0005151: FP不是只是first call function就是FP 06/25 13:22
7F：→ w0005151: *first class function 06/25 13:23
8F：推 brucetu: 那你不就只有殺死策略模式-.- 舉個例子 singleton 呢？觀 06/25 13:52
9F：→ brucetu: 察者 / 裝飾器 / 發布訂閱等等常用的模式呢？你把這些拿 06/25 13:52
10F：→ brucetu: 出來看再看看 FP 再學一下 javascript 這種超高自由度的 06/25 13:52
11F：→ brucetu: 語言，再重新下結論不遲 06/25 13:52
12F：→ brucetu: 即使是 JS 也會用到各種設計模式 06/25 13:53
13F：→ brucetu: 高內聚低耦合可測試才是重點，OO或FP不重要也可以混用 06/25 14:00
14F：推 wei115: 設計模式也要看語言八 有些設計模式是在補語法的問題 06/25 14:37
15F：→ wei115: 有語言特性支援，很多技巧可以省略 06/25 14:38
16F：推 MoonCode: 還要配上好的型別系統才能用的爽 06/25 14:39
17F：推 black2575: 殺死Pattern 不是好事嗎 如果今天語言能解決對應問題 06/25 15:30
18F：→ black2575: 我不就不需要另外尻這些Pattern了 06/25 15:30
19F：→ Lordaeron: 台灣的另一個有趣的現象，就是大家的案子，基本上沒幾 06/25 15:50
20F：→ Lordaeron: 個"物件"會重用的，但大家就是天天design pattern. 06/25 15:50
21F：推 NDark: 那就是overdesign 06/25 16:05
22F：→ NDark: 但也跟案子的型態很有關 06/25 16:06
23F：→ NDark: 週期太短 產品風險太高無法迴避的 線上正常的 要減少重構 06/25 16:06
24F：→ NDark: 新code可以用更好的方法去實現 但不要回頭為了重用而重改 06/25 16:07
25F：→ NDark: 換言之 不是重構程式碼 而是重構人的思維模式 06/25 16:07
26F：推 mercurycgt68: 前公司架構師：我入行這幾年 06/25 16:49
27F：→ mercurycgt68: 從來不需要用什麼design pattern 06/25 16:49
28F：推 NDark: 不用的原因有可能已經是無招勝有招 06/25 16:50
29F：→ NDark: 因為對工作於設計模式出現之前的也是會有方法解決問題 06/25 16:51
30F：→ NDark: 設計模式只是把那些方法歸類取名 06/25 16:51
31F：→ NDark: 所以 不用 指得不是不用方法 而是那時還不叫設計模式 06/25 16:51
32F：推 abccbaandy: 推19F，一堆整個開發週期都只有一個impl的在那邊定 06/25 16:53
33F：→ abccbaandy: interface超87，不定還會森77說你開發習慣不好XD 06/25 16:53
34F：→ NDark: 這就是overdesign 沒有擴充需求應是搞需求出來 06/25 16:57
35F：→ NDark: 設計是為了需求服務 這點很多人沒搞懂 06/25 16:57
36F：→ NDark: 在需求很不明確或是可以預期跳躍的時候 要盡量少系統與架構 06/25 16:58
37F：推 k798976869: FP就是一種可以一直串的設計模式啊 要盡量寫pure func 06/25 18:41
38F：→ k798976869: tion 06/25 18:41
39F：推 wulouise: 原來fp是說functional programming.. DP就是有需要才用 06/25 18:47
40F：→ recorriendo: 你說的模式本身就可以當作是FP和OOP的結合 06/25 19:16
41F：→ recorriendo: 基本的OOP 每個物件就可以視為帶有一組"背景資料" 06/25 19:18
42F：→ recorriendo: 但方法函式不能"動態擴充" 06/25 19:18
43F：→ recorriendo: 而純FP則是沒有context的概念 你的模式等於把兩方 06/25 19:20
44F：→ recorriendo: 加上各自缺少的部分 06/25 19:20
45F：→ recorriendo: 有沒有必要當然是取決於現實需求 06/25 19:21
46F：→ KY1998: 你應該多看原始碼，其實用不少，你同事會不會又是另一回事 06/25 20:50
47F：推 blackdiz: 這支影片的觀點滿類似的，可以參考看看 06/25 21:29
49F：推 foxbrush: *定義Interface都省了，只要函數簽名相同都行* <= 你自 06/25 21:56
50F：→ foxbrush: 己都說了函數簽名仍要相同，不過是語言特性省去寫Interf 06/25 21:56
51F：→ foxbrush: ace，還是一樣的pattern 06/25 21:56
52F：→ superpandal: 設計模式就是oop如Java 因為語言限制而產生的經驗法 06/25 23:32
53F：→ superpandal: 則 即便你不知道什麼叫作策略模式 你依照限制依究能 06/25 23:34
54F：→ superpandal: 產生出來而不用看書 只有這類的語言才講究這種東西 06/25 23:36
55F：→ superpandal: fp或動態語言很爽的其實可以不用管這種東西 而程式碼 06/25 23:40
56F：→ superpandal: 品質最終還是取決於個人的心態和目的 06/25 23:41
57F：→ superpandal: 記得在對岸論壇看過某句話很有道理 忘記在哪 大概意 06/26 00:05
58F：→ superpandal: 思是人們發明新概念與觀點方式用來解決問題 然而該事 06/26 00:07
59F：→ superpandal: 物會用某種型式反過來束縛你 06/26 00:08
60F：→ superpandal: 不過意思差不多可以類比成獨孤九劍和一般劍法 06/26 00:10
61F：推 vi000246: 看情況吧 如果你是要寫一個plugin給別人用 定interface 06/26 00:31
62F：→ vi000246: 就滿重要的 就好像電線之於插座 用電線可以接上任何電 06/26 00:32
63F：→ vi000246: 器 但要是220v接到100v呢 這時就需要靠interface來限定 06/26 00:32
64F：→ vi000246: 接口長怎樣 06/26 00:32
65F：→ vi000246: 這世界的電器百百種 有個既成的規格可以讓電器開發商 06/26 00:34
66F：→ vi000246: 不需煩惱接口的事 當然小專案就不需要考慮這些了 06/26 00:35
67F：→ vi000246: 能動比較重要 06/26 00:35
68F：推 abccbaandy: 樓上這種教科書般的例子實際很少有吧，真要說手機快充 06/26 00:49
69F：→ abccbaandy: 不也搞了一堆特規... 06/26 00:49
70F：→ DrTech: 台灣沒什麼人在寫十萬行起跳的程式碼framework，不用開發f 06/26 02:16
71F：→ DrTech: ramework給百人，千人，萬人用。當然覺得不需要設計模式。 06/26 02:16
72F：→ DrTech: 你寫的程式頂多幾千行，頂多2-3個人會看第二次，就很了不 06/26 02:16
73F：→ DrTech: 起了。當然不需要設計模式也能做得更好。 06/26 02:16
74F：→ DrTech: 設計模式的聖經書書名都說了：Elements of Reusable Objec 06/26 02:21
75F：→ DrTech: t-Oriented Software 06/26 02:21
76F：→ DrTech: 因為你寫的，不需要一直給別人重複使用，當然不需要設計模 06/26 02:22
77F：→ DrTech: 式。 06/26 02:22
78F：→ brucetu: 讓我用綠豆糕的角度回答這個問題，我覺得設計模式是許多 06/26 08:28
79F：→ brucetu: 種可用來描述演算法的常用模式，一個問題可以有多種不同 06/26 08:28
80F：→ brucetu: 的解，你的解題思路不同就會選用不同的模式，倒不一定是 06/26 08:28
81F：→ brucetu: 為了重用程式碼。就像一個問題可以迴圈解也可以遞迴解， 06/26 08:28
82F：→ brucetu: 也還可以用狀態機解。套用模式的好處是別人容易看懂你在 06/26 08:29
83F：→ brucetu: 做什麼 06/26 08:29
84F：→ recorriendo: 沒有完美的語言 模式也只是前人在補強功能的各種方 06/26 08:36
85F：→ recorriendo: 式中歸納出來供人借鑒的 06/26 08:36
86F：→ recorriendo: 這些被歸納出來的模式 就是有經過時間證明其價值 06/26 08:36
87F：→ recorriendo: 要不照模式 當然可以 不過多數時候是幾個月後就會 06/26 08:36
88F：→ recorriendo: 後悔當初自以為的天才hack 06/26 08:36
89F：→ superpandal: 十萬行的多數是屎山 最少行數最簡短的實現一樣的功能 06/26 09:25
90F：→ superpandal: 才是好的 物件導向也只是其中一種方式 06/26 09:27
91F：→ superpandal: 這就是套路或者稱作是定石摟 然而並不需要專門去學才 06/26 09:32
92F：→ superpandal: 會了解 如上所說 這只是限制下的經驗 看了這篇說實話 06/26 09:33
93F：噓 WTS2accuracy: 什麼鬼邏輯...FP只是換個方式實作設計模式而已 06/26 09:34
94F：→ superpandal: 我也不知道什麼叫作策略模式 但我就寫出一模一樣的東 06/26 09:34
95F：→ superpandal: 西過 06/26 09:34
96F：→ superpandal: 要看語言本身特性 對很多語言來講是可以跳過這環節的 06/26 09:36
97F：推 zxcasdjason1: 個人淺見是，設計模式像心法，OO, FP 則像外功。FP 06/26 11:38
98F：→ zxcasdjason1: 是否好用，還是要看你用的語言特性，像原po提到的J 06/26 11:38
99F：→ zxcasdjason1: S， class 只是語法糖，跟 java, c#, 本質就不同， 06/26 11:38
100F：→ zxcasdjason1: 對 JS 來說，用 function 更直覺。 自己工作上從 O 06/26 11:38
101F：→ zxcasdjason1: O 轉 FP 一段時間， 相比 OO 來說，FP 設計上講究 06/26 11:38
102F：→ zxcasdjason1: 狀態皆來自參數，無副作用的函式測試好寫，也好維 06/26 11:38
103F：→ zxcasdjason1: 護。 06/26 11:38
104F：推 wulouise: 咦原來十萬就是很多了... 06/26 12:54
105F：→ ma721: 自己跟別人看好懂好維護就行 06/26 14:01
106F：→ KY1998: JS轉TS時，generics應該會讓你不太爽 06/26 14:19
107F：→ superpandal: 實際上設計模式還是外功 你整的再好也只是在上面玩耍 06/26 15:46
108F：→ superpandal: 能整到十萬我懷疑它的品質以及可維護程式可控性 06/26 15:49
109F：→ angusyu: 怎麼可能取代策略模式…我一樣用策略模式不會塞lambda 06/26 20:30
110F：推 Lipraxde: 寫十萬行 code... 有兩種，一種是需要寫十萬行...另一 06/26 20:36
111F：→ Lipraxde: 種是寫了十萬行，就像 design pattern 一樣，一種是需 06/26 20:36
112F：→ Lipraxde: 要用...另一種是用下去了 06/26 20:36
113F：→ viper9709: 台灣的軟體生命週期太短+1 06/26 21:19
114F：→ peter98: design pattern常用的可以用，不常用的就別用，很多desig 06/26 22:55
115F：→ peter98: n pattern寫到最後會讓人無法trace code，如果只是個幾萬 06/26 22:56
116F：→ peter98: 行而已的專案就別全部硬要套design pattern了，常用的倒 06/26 22:56
117F：→ peter98: 是可以用，比如builder/factory/singleton/deco等 06/26 22:56
118F：→ peter98: 另外台灣的軟體不是軟體，板子換了軟體重寫，也不需要用 06/26 22:57
119F：→ peter98: design pattern，寫code可以hardcode就好，速度快，出錯 06/26 22:58
120F：→ peter98: 也沒關係，反正出bug的時候，該軟體可能都快結束生命了 06/26 22:58
121F：→ peter98: 反正出問題也不需要再修~ 何必搞design pattern? 06/26 22:58
122F：→ appleway: 不同的語言有不同的DP. Haskell有lens 但是Java不用 06/26 23:24
123F：推 CoNsTaR: FP 以外唯一支持 C++ TMP，C++20/23 加上 boost::mp11 06/27 01:34
124F：→ CoNsTaR: 根本 compile-time dependent type，幾乎是想做什麼都可 06/27 01:34
125F：→ CoNsTaR: 以幫你 type check 06/27 01:34
126F：→ CoNsTaR: 傳統設計模式相較之下就像是二維平面的小孩玩具一樣幫 QQ 06/27 01:34
127F：→ Suleika: interface寫好，設計想得很好，結果同類型新專案不拿去 06/27 17:10
128F：→ Suleika: 共用的場景太多了，寫的讓同事看得懂優先級可能高點 06/27 17:10
129F：推 ko27tye: 選擇用什麼pattern之前 先考慮同事的程度吧 06/27 19:23
130F：→ Lipraxde: Builder 跟 factory 不是很讓人喜歡...看到生搬硬套的 06/27 20:28
131F：→ Lipraxde: 用法就很討厭 06/27 20:28
132F：推 jhjhs33504: 不需要幫印度人歸納的方法背書很多模式在OS,APP能找到 06/29 10:00
133F：推 legion87: 了解每個pattern的精神就好，很多程式碼的語法精進的本 07/06 17:14
134F：→ legion87: 身就已經包含了一些設計模式的概念了 07/06 17:14
135F：→ legion87: 不是說一定要套用最原本的class diagram才叫設計模式 07/06 17:15
136F：→ legion87: Java的enum一出來，策略模式的寫法都改變了，但精神上還 07/06 17:16
137F：→ legion87: 是策略模式 07/06 17:16
138F：推 dickgg: 其實 FP 歷史是早於 OO 的，只是後來OO 比較紅。比較像是 07/09 23:42
139F：→ dickgg: 純的 FP 不好懂所以流行 OO + DP 07/09 23:42