作者
標題 [討論] FP正在殺死設計模式嗎？
時間 Tue Jun 25 11:02:11 2024
標題 [討論] FP正在殺死設計模式嗎？
時間 Tue Jun 25 11:02:11 2024
拿策略模式舉例，因為正好在研究這個
http://i.imgur.com/UWc8gR6.jpg
![[圖]](https://i.imgur.com/UWc8gR6.png)
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 (臺灣)
※ 作者: ohmylove347 2024-06-25 11:02:11
※ 文章代碼(AID): #1cUZCuPN (Soft_Job)
※ 文章網址: 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
![]()
--
※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:06:15
推 : 設計模式，是從OO長出來的....
跟殺死沒關係。就不適用1F 06/25 11:12
※ 編輯: ohmylove347 (114.136.159.79 臺灣), 06/25/2024 11:14:51跟殺死沒關係。就不適用1F 06/25 11:12
→ : OO就跟Scrum是一種理所當然 專注在他們想解決的課題才合理3F 06/25 11:14
推 : 是的 很多情境下可以設計更簡單，傳參數就好了4F 06/25 11:53
→ : 你的例子還是策略模式啊，只是interface省了而已
FP不是只是first call function就是FP
*first class function5F 06/25 13:22
FP不是只是first call function就是FP
*first class function5F 06/25 13:22
推 : 那你不就只有殺死策略模式-.- 舉個例子 singleton 呢？觀察者 / 裝飾器 / 發布訂閱等等常用的模式呢？你把這些拿出來看再看看 FP 再學一下 javascript 這種超高自由度的語言，再重新下結論不遲
即使是 JS 也會用到各種設計模式
高內聚低耦合可測試才是重點，OO或FP不重要也可以混用8F 06/25 13:52
即使是 JS 也會用到各種設計模式
高內聚低耦合可測試才是重點，OO或FP不重要也可以混用8F 06/25 13:52
推 : 設計模式也要看語言八 有些設計模式是在補語法的問題
有語言特性支援，很多技巧可以省略14F 06/25 14:37
有語言特性支援，很多技巧可以省略14F 06/25 14:37
推 : 還要配上好的型別系統才能用的爽16F 06/25 14:39
推 : 殺死Pattern 不是好事嗎 如果今天語言能解決對應問題我不就不需要另外尻這些Pattern了17F 06/25 15:30
→ : 台灣的另一個有趣的現象，就是大家的案子，基本上沒幾個"物件"會重用的，但大家就是天天design pattern.19F 06/25 15:50
推 : 那就是overdesign
但也跟案子的型態很有關
週期太短 產品風險太高無法迴避的 線上正常的 要減少重構新code可以用更好的方法去實現 但不要回頭為了重用而重改換言之 不是重構程式碼 而是重構人的思維模式21F 06/25 16:05
但也跟案子的型態很有關
週期太短 產品風險太高無法迴避的 線上正常的 要減少重構新code可以用更好的方法去實現 但不要回頭為了重用而重改換言之 不是重構程式碼 而是重構人的思維模式21F 06/25 16:05
推 : 前公司架構師：我入行這幾年
從來不需要用什麼design pattern26F 06/25 16:49
從來不需要用什麼design pattern26F 06/25 16:49
推 : 不用的原因有可能已經是無招勝有招
因為對工作於設計模式出現之前的也是會有方法解決問題
設計模式只是把那些方法歸類取名
所以 不用 指得不是不用方法 而是那時還不叫設計模式28F 06/25 16:50
因為對工作於設計模式出現之前的也是會有方法解決問題
設計模式只是把那些方法歸類取名
所以 不用 指得不是不用方法 而是那時還不叫設計模式28F 06/25 16:50
推 : 推19F，一堆整個開發週期都只有一個impl的在那邊定
interface超87，不定還會森77說你開發習慣不好XD32F 06/25 16:53
interface超87，不定還會森77說你開發習慣不好XD32F 06/25 16:53
→ : 這就是overdesign 沒有擴充需求應是搞需求出來
設計是為了需求服務 這點很多人沒搞懂
在需求很不明確或是可以預期跳躍的時候 要盡量少系統與架構34F 06/25 16:57
設計是為了需求服務 這點很多人沒搞懂
在需求很不明確或是可以預期跳躍的時候 要盡量少系統與架構34F 06/25 16:57
推 : FP就是一種可以一直串的設計模式啊 要盡量寫pure function37F 06/25 18:41
推 : 原來fp是說functional programming.. DP就是有需要才用39F 06/25 18:47
→ : 你說的模式本身就可以當作是FP和OOP的結合
基本的OOP 每個物件就可以視為帶有一組"背景資料" 但方法函式不能"動態擴充"
而純FP則是沒有context的概念 你的模式等於把兩方加上各自缺少的部分
有沒有必要當然是取決於現實需求40F 06/25 19:16
基本的OOP 每個物件就可以視為帶有一組"背景資料" 但方法函式不能"動態擴充"
而純FP則是沒有context的概念 你的模式等於把兩方加上各自缺少的部分
有沒有必要當然是取決於現實需求40F 06/25 19:16
→ : 你應該多看原始碼，其實用不少，你同事會不會又是另一回事46F 06/25 20:50
推 : *定義Interface都省了，只要函數簽名相同都行* <= 你自己都說了函數簽名仍要相同，不過是語言特性省去寫Interface，還是一樣的pattern49F 06/25 21:56
→ : 設計模式就是oop如Java 因為語言限制而產生的經驗法則 即便你不知道什麼叫作策略模式 你依照限制依究能產生出來而不用看書 只有這類的語言才講究這種東西fp或動態語言很爽的其實可以不用管這種東西 而程式碼品質最終還是取決於個人的心態和目的
記得在對岸論壇看過某句話很有道理 忘記在哪 大概意思是人們發明新概念與觀點方式用來解決問題 然而該事物會用某種型式反過來束縛你
不過意思差不多可以類比成獨孤九劍和一般劍法52F 06/25 23:32
記得在對岸論壇看過某句話很有道理 忘記在哪 大概意思是人們發明新概念與觀點方式用來解決問題 然而該事物會用某種型式反過來束縛你
不過意思差不多可以類比成獨孤九劍和一般劍法52F 06/25 23:32
推 : 看情況吧 如果你是要寫一個plugin給別人用 定interface就滿重要的 就好像電線之於插座 用電線可以接上任何電器 但要是220v接到100v呢 這時就需要靠interface來限定接口長怎樣
這世界的電器百百種 有個既成的規格可以讓電器開發商
不需煩惱接口的事 當然小專案就不需要考慮這些了
能動比較重要61F 06/26 00:31
這世界的電器百百種 有個既成的規格可以讓電器開發商
不需煩惱接口的事 當然小專案就不需要考慮這些了
能動比較重要61F 06/26 00:31
推 : 樓上這種教科書般的例子實際很少有吧，真要說手機快充不也搞了一堆特規...68F 06/26 00:49
→ : 台灣沒什麼人在寫十萬行起跳的程式碼framework，不用開發framework給百人，千人，萬人用。當然覺得不需要設計模式。你寫的程式頂多幾千行，頂多2-3個人會看第二次，就很了不起了。當然不需要設計模式也能做得更好。
設計模式的聖經書書名都說了：Elements of Reusable Object-Oriented Software
因為你寫的，不需要一直給別人重複使用，當然不需要設計模式。70F 06/26 02:16
設計模式的聖經書書名都說了：Elements of Reusable Object-Oriented Software
因為你寫的，不需要一直給別人重複使用，當然不需要設計模式。70F 06/26 02:16
→ : 讓我用綠豆糕的角度回答這個問題，我覺得設計模式是許多種可用來描述演算法的常用模式，一個問題可以有多種不同的解，你的解題思路不同就會選用不同的模式，倒不一定是為了重用程式碼。就像一個問題可以迴圈解也可以遞迴解，也還可以用狀態機解。套用模式的好處是別人容易看懂你在做什麼78F 06/26 08:28
→ : 沒有完美的語言 模式也只是前人在補強功能的各種方式中歸納出來供人借鑒的
這些被歸納出來的模式 就是有經過時間證明其價值
要不照模式 當然可以 不過多數時候是幾個月後就會後悔當初自以為的天才hack84F 06/26 08:36
這些被歸納出來的模式 就是有經過時間證明其價值
要不照模式 當然可以 不過多數時候是幾個月後就會後悔當初自以為的天才hack84F 06/26 08:36
→ : 十萬行的多數是屎山 最少行數最簡短的實現一樣的功能才是好的 物件導向也只是其中一種方式
這就是套路或者稱作是定石摟 然而並不需要專門去學才會了解 如上所說 這只是限制下的經驗 看了這篇說實話89F 06/26 09:25
這就是套路或者稱作是定石摟 然而並不需要專門去學才會了解 如上所說 這只是限制下的經驗 看了這篇說實話89F 06/26 09:25
噓 : 什麼鬼邏輯...FP只是換個方式實作設計模式而已93F 06/26 09:34
→ : 我也不知道什麼叫作策略模式 但我就寫出一模一樣的東西過
要看語言本身特性 對很多語言來講是可以跳過這環節的94F 06/26 09:34
要看語言本身特性 對很多語言來講是可以跳過這環節的94F 06/26 09:34
推 : 個人淺見是，設計模式像心法，OO, FP 則像外功。FP是否好用，還是要看你用的語言特性，像原po提到的JS， class 只是語法糖，跟 java, c#, 本質就不同，對 JS 來說，用 function 更直覺。 自己工作上從 OO 轉 FP 一段時間， 相比 OO 來說，FP 設計上講究狀態皆來自參數，無副作用的函式測試好寫，也好維護。97F 06/26 11:38
推 : 咦原來十萬就是很多了...104F 06/26 12:54
--