拿策略模式舉例，因為正好在研究這個
http://i.imgur.com/UWc8gR6.jpgContext 和 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.
--
sw121樓設計模式，是從OO長出來的.... 06/25 11:12
→ sw122樓跟殺死沒關係。就不適用 06/25 11:12
→ NDark3樓OO就跟Scrum是一種理所當然 專注在他們想解決的課題才合理 06/25 11:14
papa5104樓是的 很多情境下可以設計更簡單，傳參數就好了 06/25 11:53
→ w00051515樓你的例子還是策略模式啊，只是interface省了而已 06/25 13:22
→ w00051516樓FP不是只是first call function就是FP 06/25 13:22
→ w00051517樓*first class function 06/25 13:23
brucetu8樓那你不就只有殺死策略模式-.- 舉個例子 singleton 呢？觀 06/25 13:52
→ brucetu9樓察者 / 裝飾器 / 發布訂閱等等常用的模式呢？你把這些拿 06/25 13:52
→ brucetu10樓出來看再看看 FP 再學一下 javascript 這種超高自由度的 06/25 13:52
→ brucetu11樓語言，再重新下結論不遲 06/25 13:52
→ brucetu12樓即使是 JS 也會用到各種設計模式 06/25 13:53
→ brucetu13樓高內聚低耦合可測試才是重點，OO或FP不重要也可以混用 06/25 14:00
wei11514樓設計模式也要看語言八 有些設計模式是在補語法的問題 06/25 14:37
→ wei11515樓有語言特性支援，很多技巧可以省略 06/25 14:38
MoonCode16樓還要配上好的型別系統才能用的爽 06/25 14:39
black257517樓殺死Pattern 不是好事嗎 如果今天語言能解決對應問題 06/25 15:30
→ black257518樓我不就不需要另外尻這些Pattern了 06/25 15:30
→ Lordaeron19樓台灣的另一個有趣的現象，就是大家的案子，基本上沒幾 06/25 15:50
→ Lordaeron20樓個"物件"會重用的，但大家就是天天design pattern. 06/25 15:50
NDark21樓那就是overdesign 06/25 16:05
→ NDark22樓但也跟案子的型態很有關 06/25 16:06
→ NDark23樓週期太短 產品風險太高無法迴避的 線上正常的 要減少重構 06/25 16:06
→ NDark24樓新code可以用更好的方法去實現 但不要回頭為了重用而重改 06/25 16:07
→ NDark25樓換言之 不是重構程式碼 而是重構人的思維模式 06/25 16:07
mercurycgt6826樓前公司架構師：我入行這幾年 06/25 16:49
→ mercurycgt6827樓從來不需要用什麼design pattern 06/25 16:49
NDark28樓不用的原因有可能已經是無招勝有招 06/25 16:50
→ NDark29樓因為對工作於設計模式出現之前的也是會有方法解決問題 06/25 16:51
→ NDark30樓設計模式只是把那些方法歸類取名 06/25 16:51
