PTT評價

[請益] 如何選擇適合的設計模式

看板Soft_Job標題[請益] 如何選擇適合的設計模式作者
azoaho
(歷史洪流)
時間推噓18 推:20 噓:2 →:37

小弟在設計系統的功能時,時常會不知該用什麼準則來判斷適合的模式

之前曾在某個網站中看到同一個問題,拿來套進 23 個模式之中
當下看完後,心想:所以大部份的問題都可以任意套用模式?

應該不是這樣子,否則四人幫就沒有必要把它們分成三大類了

那到底該如何決擇正確的模式
這個問題一直困擾著…

例如訂單依國別計算不同費用
這問題是用工廠好?還是策略好?

懇請大大們解惑

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.234.121.60 (臺灣)
PTT 網址

qwer33885911/04 23:26策略吧 為啥會用工廠?

qwer33885911/04 23:26其實很多時候不用為套而套吧會把簡單東西複雜化

WaterLengend11/04 23:28等你想怎樣寫你最好改也最能看得懂的時候,不知不

WaterLengend11/04 23:28覺就會用上了。

viper970911/04 23:30推樓上

vi00024611/04 23:34你聽過太極拳或獨孤九劍嗎 不要拘泥於招式 無招勝有招

prag22211/04 23:46我自稱DP哥 工廠模式COMBO策略模式 很常用的

devilkool11/05 00:02最好的方法就是你寫一遍

unixxxx11/05 00:15DP 是武功 SOLID 是心法 先練心法才看得懂武功

lturtsamuel11/05 00:46認真說 遇到的時候問題會告訴你該用什麼模式 不然就

lturtsamuel11/05 00:46是問題還不夠清楚 這時候最好別亂用

lturtsamuel11/05 00:48可以去看舊程式碼或開源專案 感受一下別人用設計模式

lturtsamuel11/05 00:48是在幹嘛 只看書上的其實你都感受不到那個規模

lturtsamuel11/05 00:48像 visitor pattern 就可以去看看 rust serde 函式庫

lturtsamuel11/05 00:48怎麼用的

lturtsamuel11/05 00:54濫用模式跟不用模式硬要選一個 大家應該都會選後者

t6414111/05 01:35先重構, 重構的過程有機會發現變成某幾種模式

t6414111/05 01:35的形狀

t6414111/05 01:41但如果情境單純, 也不用硬要重構或是找出什麼模式就是

umum2911/05 01:52先重構+1 如果你發現一直寫重複的代碼就是一種徵兆

umum2911/05 01:55用工廠的情況也不少 例:多個supplier的connectio量身訂作

qscesz145611/05 02:00模式是在解決你的需求 所以很常都會有一些變形或組合

qscesz145611/05 02:00 依據自己經驗去設計 最後會發現你的東西就是某個模

qscesz145611/05 02:00式的樣子

peter9811/05 03:11你可以先挑一個來玩 builder最容易上手最好改

OnlyRD11/05 03:41一開始先別想太多設計模式是要慢慢修剪的

RumiManiac11/05 07:24你可以讀 Refactoring to patterns

RumiManiac11/05 07:24首先要能辨識 smells, 然後透過重構改為設計模式

RumiManiac11/05 07:26不只可以學習何時該使用設計模式,也能避免過度設計

RINPE11/05 07:30公司的東西的話 很簡單 都是看薪水給多少

final0111/05 07:34認真看一下書。。。我覺得你肯定沒看書網路文章隨便看

final0111/05 07:34然後整天幻想要怎麼設計不如認真讀書。。。

soccer10311/05 08:37先重構 +1

soccer10311/05 08:37過程中應該會有使用哪個模式想法了

soccer10311/05 08:37剛學設計模式切忌看到什麼 code 就想把它改成設計模式

soccer10311/05 08:37避免為用而用

vi00024611/05 08:43最近看到同事為用而用 反而寫出難以維護的程式碼

vi00024611/05 08:44看起來很厲害 讀起來很痛苦 而且還不符合solid原則

bheegrl11/05 09:00別做出ide都沒辦法幫你trace code就行

bheegrl11/05 09:03#不然接手幫忙修BUG的人會一直問候你親人

bheegrl11/05 09:05最好是有需求、有痛點再去找解決方案,不然容易寫出狗屎

bheegrl11/05 09:07不然一般來說專案架構簡單好維護比什麼都重要

godsparticle11/05 09:08我看過太多過度設計的例子了

wilson640511/05 09:18先寫一堆爛code然後看相關書籍,然後重構爛code

sowulo11/05 10:27設計模式的出發點都是可讀可維護好擴充 掌握原則就好了

MonyemLi11/05 14:17你對你的程式要有改進的熱誠. do it. pattern自然出現

Darkword198711/05 15:28我覺得先有點經驗再去學design pattern比較實在 一

Darkword198711/05 15:28堆人連繼承多型都不知道該何時用

JustinHere11/05 18:22問這個問題時,就表示哪個都不該選…XD

johnny9411/05 18:45首先你要認知到的是模式只能當作一種指引,而不是像公式

johnny9411/05 18:45一樣讓你拿來套的

viper970911/05 23:39推濫用不如不用+1

jennya11/06 00:00一堆網頁和書都在教壞人硬套設計模式,這個噓是給他們的

jennya11/06 00:00。在工作上遇到那種設計模式硬套寫出來的可怕code真的讓

jennya11/06 00:00後人白多花一堆時間去理解、而且又在有人疊床架屋繼續從

jennya11/06 00:00不好的架構去發展的話,整個很慘,說真的,不套模式都還

jennya11/06 00:00好多了

iamshiao11/09 00:15實作越多年,越覺得 DP 不用特意學/背,需要的情景自然

iamshiao11/09 00:15會查到