PTT職涯區 / Soft_Job (軟體人)

[討論] FP正在殺死設計模式嗎？

看板Soft_Job (軟體人)作者 (米特巴爾)時間5月前 (2024/06/25 11:02), 5月前編輯推噓23(24推 1噓 114→)
留言139則, 34人參與, 4月前最新討論串1/2 (看更多)
拿策略模式舉例，因為正好在研究這個 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
推
06/25 11:12, 5月前 , 1F
設計模式，是從OO長出來的....
06/25 11:12, 1F
→
06/25 11:12, 5月前 , 2F
跟殺死沒關係。就不適用
06/25 11:12, 2F
※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:14:51
→
06/25 11:14, 5月前 , 3F
OO就跟Scrum是一種理所當然 專注在他們想解決的課題才合理
06/25 11:14, 3F
推
06/25 11:53, 5月前 , 4F
是的 很多情境下可以設計更簡單，傳參數就好了
06/25 11:53, 4F
→
06/25 13:22, 5月前 , 5F
你的例子還是策略模式啊，只是interface省了而已
06/25 13:22, 5F
→
06/25 13:22, 5月前 , 6F
FP不是只是first call function就是FP
06/25 13:22, 6F
→
06/25 13:23, 5月前 , 7F
*first class function
06/25 13:23, 7F
推
06/25 13:52, 5月前 , 8F
那你不就只有殺死策略模式-.- 舉個例子 singleton 呢？觀
06/25 13:52, 8F
→
06/25 13:52, 5月前 , 9F
察者 / 裝飾器 / 發布訂閱等等常用的模式呢？你把這些拿
06/25 13:52, 9F
→
06/25 13:52, 5月前 , 10F
出來看再看看 FP 再學一下 javascript 這種超高自由度的
06/25 13:52, 10F
→
06/25 13:52, 5月前 , 11F
語言，再重新下結論不遲
06/25 13:52, 11F
→
06/25 13:53, 5月前 , 12F
即使是 JS 也會用到各種設計模式
06/25 13:53, 12F
→
06/25 14:00, 5月前 , 13F
高內聚低耦合可測試才是重點，OO或FP不重要也可以混用
06/25 14:00, 13F
推
06/25 14:37, 5月前 , 14F
設計模式也要看語言八 有些設計模式是在補語法的問題
06/25 14:37, 14F
→
06/25 14:38, 5月前 , 15F
有語言特性支援，很多技巧可以省略
06/25 14:38, 15F
推
06/25 14:39, 5月前 , 16F
還要配上好的型別系統才能用的爽
06/25 14:39, 16F
推
06/25 15:30, 5月前 , 17F
殺死Pattern 不是好事嗎 如果今天語言能解決對應問題
06/25 15:30, 17F
→
06/25 15:30, 5月前 , 18F
我不就不需要另外尻這些Pattern了
06/25 15:30, 18F
→
06/25 15:50, 5月前 , 19F
台灣的另一個有趣的現象，就是大家的案子，基本上沒幾
06/25 15:50, 19F
→
06/25 15:50, 5月前 , 20F
個"物件"會重用的，但大家就是天天design pattern.
06/25 15:50, 20F
推
06/25 16:05, 5月前 , 21F
那就是overdesign
06/25 16:05, 21F
→
06/25 16:06, 5月前 , 22F
但也跟案子的型態很有關
06/25 16:06, 22F
→
06/25 16:06, 5月前 , 23F
週期太短 產品風險太高無法迴避的 線上正常的 要減少重構
06/25 16:06, 23F
→
06/25 16:07, 5月前 , 24F
新code可以用更好的方法去實現 但不要回頭為了重用而重改
06/25 16:07, 24F
→
06/25 16:07, 5月前 , 25F
換言之 不是重構程式碼 而是重構人的思維模式
06/25 16:07, 25F
推
06/25 16:49, 5月前 , 26F
前公司架構師：我入行這幾年
06/25 16:49, 26F
→
06/25 16:49, 5月前 , 27F
從來不需要用什麼design pattern
06/25 16:49, 27F
推
06/25 16:50, 5月前 , 28F
不用的原因有可能已經是無招勝有招
06/25 16:50, 28F
→
06/25 16:51, 5月前 , 29F
因為對工作於設計模式出現之前的也是會有方法解決問題
06/25 16:51, 29F
→
06/25 16:51, 5月前 , 30F
設計模式只是把那些方法歸類取名
06/25 16:51, 30F
→
06/25 16:51, 5月前 , 31F
所以 不用 指得不是不用方法 而是那時還不叫設計模式
06/25 16:51, 31F
推
06/25 16:53, 5月前 , 32F
推19F，一堆整個開發週期都只有一個impl的在那邊定
06/25 16:53, 32F
→
06/25 16:53, 5月前 , 33F
interface超87，不定還會森77說你開發習慣不好XD
06/25 16:53, 33F
→
06/25 16:57, 5月前 , 34F
這就是overdesign 沒有擴充需求應是搞需求出來
06/25 16:57, 34F
→
06/25 16:57, 5月前 , 35F
設計是為了需求服務 這點很多人沒搞懂
06/25 16:57, 35F
→
06/25 16:58, 5月前 , 36F
在需求很不明確或是可以預期跳躍的時候 要盡量少系統與架構
06/25 16:58, 36F
推
06/25 18:41, 5月前 , 37F
FP就是一種可以一直串的設計模式啊 要盡量寫pure func
06/25 18:41, 37F
→
06/25 18:41, 5月前 , 38F
tion
06/25 18:41, 38F
還有 61 則推文
→
06/26 11:38, 5月前 , 100F
對 JS 來說，用 function 更直覺。 自己工作上從 O
06/26 11:38, 100F
→
06/26 11:38, 5月前 , 101F
O 轉 FP 一段時間， 相比 OO 來說，FP 設計上講究
06/26 11:38, 101F
→
06/26 11:38, 5月前 , 102F
狀態皆來自參數，無副作用的函式測試好寫，也好維
06/26 11:38, 102F
→
06/26 11:38, 5月前 , 103F
護。
06/26 11:38, 103F
推
06/26 12:54, 5月前 , 104F
咦原來十萬就是很多了...
06/26 12:54, 104F
→
06/26 14:01, 5月前 , 105F
自己跟別人看好懂好維護就行
06/26 14:01, 105F
→
06/26 14:19, 5月前 , 106F
JS轉TS時，generics應該會讓你不太爽
06/26 14:19, 106F
→
06/26 15:46, 5月前 , 107F
實際上設計模式還是外功 你整的再好也只是在上面玩耍
06/26 15:46, 107F
→
06/26 15:49, 5月前 , 108F
能整到十萬我懷疑它的品質以及可維護程式可控性
06/26 15:49, 108F
→
06/26 20:30, 5月前 , 109F
怎麼可能取代策略模式…我一樣用策略模式不會塞lambda
06/26 20:30, 109F
推
06/26 20:36, 5月前 , 110F
寫十萬行 code... 有兩種，一種是需要寫十萬行...另一
06/26 20:36, 110F
→
06/26 20:36, 5月前 , 111F
種是寫了十萬行，就像 design pattern 一樣，一種是需
06/26 20:36, 111F
→
06/26 20:36, 5月前 , 112F
要用...另一種是用下去了
06/26 20:36, 112F
→
06/26 21:19, 5月前 , 113F
台灣的軟體生命週期太短+1
06/26 21:19, 113F
→
06/26 22:55, 5月前 , 114F
design pattern常用的可以用，不常用的就別用，很多desig
06/26 22:55, 114F
→
06/26 22:56, 5月前 , 115F
n pattern寫到最後會讓人無法trace code，如果只是個幾萬
06/26 22:56, 115F
→
06/26 22:56, 5月前 , 116F
行而已的專案就別全部硬要套design pattern了，常用的倒
06/26 22:56, 116F
→
06/26 22:56, 5月前 , 117F
是可以用，比如builder/factory/singleton/deco等
06/26 22:56, 117F
→
06/26 22:57, 5月前 , 118F
另外台灣的軟體不是軟體，板子換了軟體重寫，也不需要用
06/26 22:57, 118F
→
06/26 22:58, 5月前 , 119F
design pattern，寫code可以hardcode就好，速度快，出錯
06/26 22:58, 119F
→
06/26 22:58, 5月前 , 120F
也沒關係，反正出bug的時候，該軟體可能都快結束生命了
06/26 22:58, 120F
→
06/26 22:58, 5月前 , 121F
反正出問題也不需要再修~ 何必搞design pattern?
06/26 22:58, 121F
→
06/26 23:24, 5月前 , 122F
不同的語言有不同的DP. Haskell有lens 但是Java不用
06/26 23:24, 122F
推
06/27 01:34, 5月前 , 123F
FP 以外唯一支持 C++ TMP，C++20/23 加上 boost::mp11
06/27 01:34, 123F
→
06/27 01:34, 5月前 , 124F
根本 compile-time dependent type，幾乎是想做什麼都可
06/27 01:34, 124F
→
06/27 01:34, 5月前 , 125F
以幫你 type check
06/27 01:34, 125F
→
06/27 01:34, 5月前 , 126F
傳統設計模式相較之下就像是二維平面的小孩玩具一樣幫 QQ
06/27 01:34, 126F
→
06/27 17:10, 5月前 , 127F
interface寫好，設計想得很好，結果同類型新專案不拿去
06/27 17:10, 127F
→
06/27 17:10, 5月前 , 128F
共用的場景太多了，寫的讓同事看得懂優先級可能高點
06/27 17:10, 128F
推
06/27 19:23, 5月前 , 129F
選擇用什麼pattern之前 先考慮同事的程度吧
06/27 19:23, 129F
→
06/27 20:28, 5月前 , 130F
Builder 跟 factory 不是很讓人喜歡...看到生搬硬套的
06/27 20:28, 130F
→
06/27 20:28, 5月前 , 131F
用法就很討厭
06/27 20:28, 131F
推
06/29 10:00, 4月前 , 132F
不需要幫印度人歸納的方法背書很多模式在OS,APP能找到
06/29 10:00, 132F
推
07/06 17:14, 4月前 , 133F
了解每個pattern的精神就好，很多程式碼的語法精進的本
07/06 17:14, 133F
→
07/06 17:14, 4月前 , 134F
身就已經包含了一些設計模式的概念了
07/06 17:14, 134F
→
07/06 17:15, 4月前 , 135F
不是說一定要套用最原本的class diagram才叫設計模式
07/06 17:15, 135F
→
07/06 17:16, 4月前 , 136F
Java的enum一出來，策略模式的寫法都改變了，但精神上還
07/06 17:16, 136F
→
07/06 17:16, 4月前 , 137F
是策略模式
07/06 17:16, 137F
推
07/09 23:42, 4月前 , 138F
其實 FP 歷史是早於 OO 的，只是後來OO 比較紅。比較像是
07/09 23:42, 138F
→
07/09 23:42, 4月前 , 139F
純的 FP 不好懂所以流行 OO + DP
07/09 23:42, 139F
‣ 更多 ohmylove347 的文章
文章代碼(AID): #1cUZCuPN (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 ohmylove347 的文章
文章代碼(AID): #1cUZCuPN (Soft_Job)