小弟在設計系統的功能時，時常會不知該用什麼準則來判斷適合的模式
之前曾在某個網站中看到同一個問題，拿來套進 23 個模式之中
當下看完後，心想：所以大部份的問題都可以任意套用模式？
應該不是這樣子，否則四人幫就沒有必要把它們分成三大類了
那到底該如何決擇正確的模式
這個問題一直困擾著…
例如訂單依國別計算不同費用
這問題是用工廠好？還是策略好？
懇請大大們解惑

策略吧 為啥會用工廠?其實很多時候不用為套而套吧會把簡單東西複雜化

等你想怎樣寫你最好改也最能看得懂的時候，不知不覺就會用上了。

推樓上

你聽過太極拳或獨孤九劍嗎 不要拘泥於招式 無招勝有招

我自稱DP哥 工廠模式COMBO策略模式 很常用的

最好的方法就是你寫一遍

DP 是武功 SOLID 是心法 先練心法才看得懂武功

認真說 遇到的時候問題會告訴你該用什麼模式 不然就是問題還不夠清楚 這時候最好別亂用可以去看舊程式碼或開源專案 感受一下別人用設計模式是在幹嘛 只看書上的其實你都感受不到那個規模像 visitor pattern 就可以去看看 rust serde 函式庫怎麼用的濫用模式跟不用模式硬要選一個 大家應該都會選後者

先重構, 重構的過程有機會發現變成某幾種模式的形狀但如果情境單純, 也不用硬要重構或是找出什麼模式就是

先重構+1 如果你發現一直寫重複的代碼就是一種徵兆用工廠的情況也不少 例：多個supplier的connectio量身訂作

模式是在解決你的需求 所以很常都會有一些變形或組合依據自己經驗去設計 最後會發現你的東西就是某個模式的樣子

你可以先挑一個來玩 builder最容易上手最好改

一開始先別想太多設計模式是要慢慢修剪的

你可以讀 Refactoring to patterns首先要能辨識 smells, 然後透過重構改為設計模式不只可以學習何時該使用設計模式，也能避免過度設計

公司的東西的話 很簡單 都是看薪水給多少

認真看一下書。。。我覺得你肯定沒看書網路文章隨便看然後整天幻想要怎麼設計不如認真讀書。。。

先重構 +1過程中應該會有使用哪個模式想法了剛學設計模式切忌看到什麼 code 就想把它改成設計模式避免為用而用

最近看到同事為用而用 反而寫出難以維護的程式碼看起來很厲害 讀起來很痛苦 而且還不符合solid原則

別做出ide都沒辦法幫你trace code就行#不然接手幫忙修BUG的人會一直問候你親人最好是有需求、有痛點再去找解決方案，不然容易寫出狗屎不然一般來說專案架構簡單好維護比什麼都重要

我看過太多過度設計的例子了

先寫一堆爛code然後看相關書籍，然後重構爛code

設計模式的出發點都是可讀可維護好擴充 掌握原則就好了

你對你的程式要有改進的熱誠. do it. pattern自然出現

我覺得先有點經驗再去學design pattern比較實在 一堆人連繼承多型都不知道該何時用

問這個問題時，就表示哪個都不該選…XD

首先你要認知到的是模式只能當作一種指引，而不是像公式一樣讓你拿來套的

推濫用不如不用+1

一堆網頁和書都在教壞人硬套設計模式，這個噓是給他們的。在工作上遇到那種設計模式硬套寫出來的可怕code真的讓後人白多花一堆時間去理解、而且又在有人疊床架屋繼續從不好的架構去發展的話，整個很慘，說真的，不套模式都還好多了

實作越多年，越覺得 DP 不用特意學/背，需要的情景自然會查到