作者azoaho (歷史洪流)
看板Soft_Job
標題[請益] 如何選擇適合的設計模式
時間Thu Nov 4 23:19:05 2021
小弟在設計系統的功能時，時常會不知該用什麼準則來判斷適合的模式
之前曾在某個網站中看到同一個問題，拿來套進 23 個模式之中
當下看完後，心想：所以大部份的問題都可以任意套用模式？
應該不是這樣子，否則四人幫就沒有必要把它們分成三大類了
那到底該如何決擇正確的模式
這個問題一直困擾著…
例如訂單依國別計算不同費用
這問題是用工廠好？還是策略好？
懇請大大們解惑
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.234.121.60 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1636039147.A.7F6.html
1F：→ qwer338859: 策略吧 為啥會用工廠? 11/04 23:26
2F：→ qwer338859: 其實很多時候不用為套而套吧會把簡單東西複雜化 11/04 23:26
3F：推 WaterLengend: 等你想怎樣寫你最好改也最能看得懂的時候，不知不 11/04 23:28
4F：→ WaterLengend: 覺就會用上了。 11/04 23:28
5F：推 viper9709: 推樓上 11/04 23:30
6F：推 vi000246: 你聽過太極拳或獨孤九劍嗎 不要拘泥於招式 無招勝有招 11/04 23:34
7F：推 prag222: 我自稱DP哥 工廠模式COMBO策略模式 很常用的 11/04 23:46
8F：→ devilkool: 最好的方法就是你寫一遍 11/05 00:02
9F：推 unixxxx: DP 是武功 SOLID 是心法 先練心法才看得懂武功 11/05 00:15
10F：推 lturtsamuel: 認真說 遇到的時候問題會告訴你該用什麼模式 不然就 11/05 00:46
11F：→ lturtsamuel: 是問題還不夠清楚 這時候最好別亂用 11/05 00:46
12F：→ lturtsamuel: 可以去看舊程式碼或開源專案 感受一下別人用設計模式 11/05 00:48
13F：→ lturtsamuel: 是在幹嘛 只看書上的其實你都感受不到那個規模 11/05 00:48
14F：→ lturtsamuel: 像 visitor pattern 就可以去看看 rust serde 函式庫 11/05 00:48
15F：→ lturtsamuel: 怎麼用的 11/05 00:48
16F：推 lturtsamuel: 濫用模式跟不用模式硬要選一個 大家應該都會選後者 11/05 00:54
17F：推 t64141: 先重構, 重構的過程有機會發現變成某幾種模式 11/05 01:35
18F：→ t64141: 的形狀 11/05 01:35
19F：推 t64141: 但如果情境單純, 也不用硬要重構或是找出什麼模式就是 11/05 01:41
20F：推 umum29: 先重構+1 如果你發現一直寫重複的代碼就是一種徵兆 11/05 01:52
21F：→ umum29: 用工廠的情況也不少 例：多個supplier的connectio量身訂作 11/05 01:55
22F：推 qscesz1456: 模式是在解決你的需求 所以很常都會有一些變形或組合 11/05 02:00
23F：→ qscesz1456: 依據自己經驗去設計 最後會發現你的東西就是某個模 11/05 02:00
24F：→ qscesz1456: 式的樣子 11/05 02:00
25F：→ peter98: 你可以先挑一個來玩 builder最容易上手最好改 11/05 03:11
26F：推 OnlyRD: 一開始先別想太多設計模式是要慢慢修剪的 11/05 03:41
27F：→ RumiManiac: 你可以讀 Refactoring to patterns 11/05 07:24
28F：→ RumiManiac: 首先要能辨識 smells, 然後透過重構改為設計模式 11/05 07:24
29F：→ RumiManiac: 不只可以學習何時該使用設計模式，也能避免過度設計 11/05 07:26
30F：推 RINPE: 公司的東西的話 很簡單 都是看薪水給多少 11/05 07:30
31F：噓 final01: 認真看一下書。。。我覺得你肯定沒看書網路文章隨便看 11/05 07:34
32F：→ final01: 然後整天幻想要怎麼設計不如認真讀書。。。 11/05 07:34
33F：推 soccer103: 先重構 +1 11/05 08:37
34F：→ soccer103: 過程中應該會有使用哪個模式想法了 11/05 08:37
35F：→ soccer103: 剛學設計模式切忌看到什麼 code 就想把它改成設計模式 11/05 08:37
36F：→ soccer103: 避免為用而用 11/05 08:37
37F：推 vi000246: 最近看到同事為用而用 反而寫出難以維護的程式碼 11/05 08:43
38F：→ vi000246: 看起來很厲害 讀起來很痛苦 而且還不符合solid原則 11/05 08:44
39F：推 bheegrl: 別做出ide都沒辦法幫你trace code就行 11/05 09:00
40F：→ bheegrl: #不然接手幫忙修BUG的人會一直問候你親人 11/05 09:03
41F：→ bheegrl: 最好是有需求、有痛點再去找解決方案，不然容易寫出狗屎 11/05 09:05
42F：→ bheegrl: 不然一般來說專案架構簡單好維護比什麼都重要 11/05 09:07
43F：→ godsparticle: 我看過太多過度設計的例子了 11/05 09:08
44F：推 wilson6405: 先寫一堆爛code然後看相關書籍，然後重構爛code 11/05 09:18
45F：推 sowulo: 設計模式的出發點都是可讀可維護好擴充 掌握原則就好了 11/05 10:27
46F：→ MonyemLi: 你對你的程式要有改進的熱誠. do it. pattern自然出現 11/05 14:17
47F：→ Darkword1987: 我覺得先有點經驗再去學design pattern比較實在 一 11/05 15:28
48F：→ Darkword1987: 堆人連繼承多型都不知道該何時用 11/05 15:28
49F：→ JustinHere: 問這個問題時，就表示哪個都不該選…XD 11/05 18:22
50F：推 johnny94: 首先你要認知到的是模式只能當作一種指引，而不是像公式 11/05 18:45
51F：→ johnny94: 一樣讓你拿來套的 11/05 18:45
52F：推 viper9709: 推濫用不如不用+1 11/05 23:39
53F：噓 jennya: 一堆網頁和書都在教壞人硬套設計模式，這個噓是給他們的 11/06 00:00
54F：→ jennya: 。在工作上遇到那種設計模式硬套寫出來的可怕code真的讓 11/06 00:00
55F：→ jennya: 後人白多花一堆時間去理解、而且又在有人疊床架屋繼續從 11/06 00:00
56F：→ jennya: 不好的架構去發展的話，整個很慘，說真的，不套模式都還 11/06 00:00
57F：→ jennya: 好多了 11/06 00:00
58F：→ iamshiao: 實作越多年，越覺得 DP 不用特意學/背，需要的情景自然 11/09 00:15
59F：→ iamshiao: 會查到 11/09 00:15