※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1719284536.A.657.html
推 sw12: 設計模式，是從OO長出來的.... 06/25 11:12
→ sw12: 跟殺死沒關係。就不適用 06/25 11:12
→ NDark: OO就跟Scrum是一種理所當然 專注在他們想解決的課題才合理 06/25 11:14
推 papa510: 是的 很多情境下可以設計更簡單，傳參數就好了 06/25 11:53
→ w0005151: 你的例子還是策略模式啊，只是interface省了而已 06/25 13:22
→ w0005151: FP不是只是first call function就是FP 06/25 13:22
→ w0005151: *first class function 06/25 13:23
推 brucetu: 那你不就只有殺死策略模式-.- 舉個例子 singleton 呢？觀 06/25 13:52
→ brucetu: 察者 / 裝飾器 / 發布訂閱等等常用的模式呢？你把這些拿 06/25 13:52
→ brucetu: 出來看再看看 FP 再學一下 javascript 這種超高自由度的 06/25 13:52
→ brucetu: 語言，再重新下結論不遲 06/25 13:52
→ brucetu: 即使是 JS 也會用到各種設計模式 06/25 13:53
→ brucetu: 高內聚低耦合可測試才是重點，OO或FP不重要也可以混用 06/25 14:00
推 wei115: 設計模式也要看語言八 有些設計模式是在補語法的問題 06/25 14:37
→ wei115: 有語言特性支援，很多技巧可以省略 06/25 14:38
推 MoonCode: 還要配上好的型別系統才能用的爽 06/25 14:39
推 black2575: 殺死Pattern 不是好事嗎 如果今天語言能解決對應問題 06/25 15:30
→ black2575: 我不就不需要另外尻這些Pattern了 06/25 15:30
→ Lordaeron: 台灣的另一個有趣的現象，就是大家的案子，基本上沒幾 06/25 15:50
→ Lordaeron: 個"物件"會重用的，但大家就是天天design pattern. 06/25 15:50
推 NDark: 那就是overdesign 06/25 16:05
→ NDark: 但也跟案子的型態很有關 06/25 16:06
→ NDark: 週期太短 產品風險太高無法迴避的 線上正常的 要減少重構 06/25 16:06
→ NDark: 新code可以用更好的方法去實現 但不要回頭為了重用而重改 06/25 16:07
→ NDark: 換言之 不是重構程式碼 而是重構人的思維模式 06/25 16:07
推 mercurycgt68: 前公司架構師：我入行這幾年 06/25 16:49
→ mercurycgt68: 從來不需要用什麼design pattern 06/25 16:49
推 NDark: 不用的原因有可能已經是無招勝有招 06/25 16:50
→ NDark: 因為對工作於設計模式出現之前的也是會有方法解決問題 06/25 16:51
→ NDark: 設計模式只是把那些方法歸類取名 06/25 16:51
→ NDark: 所以 不用 指得不是不用方法 而是那時還不叫設計模式 06/25 16:51
推 abccbaandy: 推19F，一堆整個開發週期都只有一個impl的在那邊定 06/25 16:53
→ abccbaandy: interface超87，不定還會森77說你開發習慣不好XD 06/25 16:53
→ NDark: 這就是overdesign 沒有擴充需求應是搞需求出來 06/25 16:57
→ NDark: 設計是為了需求服務 這點很多人沒搞懂 06/25 16:57
→ NDark: 在需求很不明確或是可以預期跳躍的時候 要盡量少系統與架構 06/25 16:58
推 k798976869: FP就是一種可以一直串的設計模式啊 要盡量寫pure func 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
→ recorriendo: 基本的OOP 每個物件就可以視為帶有一組"背景資料" 06/25 19:18
→ recorriendo: 但方法函式不能"動態擴充" 06/25 19:18
→ recorriendo: 而純FP則是沒有context的概念 你的模式等於把兩方 06/25 19:20
→ recorriendo: 加上各自缺少的部分 06/25 19:20
→ recorriendo: 有沒有必要當然是取決於現實需求 06/25 19:21
→ KY1998: 你應該多看原始碼，其實用不少，你同事會不會又是另一回事 06/25 20:50
推 blackdiz: 這支影片的觀點滿類似的，可以參考看看 06/25 21:29
→ blackdiz: https://youtu.be/srQt1NAHYC0 06/25 21:29
推 foxbrush: *定義Interface都省了，只要函數簽名相同都行* <= 你自 06/25 21:56
→ foxbrush: 己都說了函數簽名仍要相同，不過是語言特性省去寫Interf 06/25 21:56
→ foxbrush: ace，還是一樣的pattern 06/25 21:56
→ superpandal: 設計模式就是oop如Java 因為語言限制而產生的經驗法 06/25 23:32
→ superpandal: 則 即便你不知道什麼叫作策略模式 你依照限制依究能 06/25 23:34
→ superpandal: 產生出來而不用看書 只有這類的語言才講究這種東西 06/25 23:36
→ superpandal: fp或動態語言很爽的其實可以不用管這種東西 而程式碼 06/25 23:40
→ superpandal: 品質最終還是取決於個人的心態和目的 06/25 23:41
→ superpandal: 記得在對岸論壇看過某句話很有道理 忘記在哪 大概意 06/26 00:05
→ superpandal: 思是人們發明新概念與觀點方式用來解決問題 然而該事 06/26 00:07
→ superpandal: 物會用某種型式反過來束縛你 06/26 00:08
→ superpandal: 不過意思差不多可以類比成獨孤九劍和一般劍法 06/26 00:10
推 vi000246: 看情況吧 如果你是要寫一個plugin給別人用 定interface 06/26 00:31
→ vi000246: 就滿重要的 就好像電線之於插座 用電線可以接上任何電 06/26 00:32
→ vi000246: 器 但要是220v接到100v呢 這時就需要靠interface來限定 06/26 00:32
→ vi000246: 接口長怎樣 06/26 00:32
→ vi000246: 這世界的電器百百種 有個既成的規格可以讓電器開發商 06/26 00:34
→ vi000246: 不需煩惱接口的事 當然小專案就不需要考慮這些了 06/26 00:35
→ vi000246: 能動比較重要 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