※ 引述《azoaho (歷史洪流)》之銘言：
: 小弟在設計系統的功能時，時常會不知該用什麼準則來判斷適合的模式
: 之前曾在某個網站中看到同一個問題，拿來套進 23 個模式之中
: 當下看完後，心想：所以大部份的問題都可以任意套用模式？
: 應該不是這樣子，否則四人幫就沒有必要把它們分成三大類了
: 那到底該如何決擇正確的模式
: 這個問題一直困擾著…
請你把clean code三本都看完
可以的話clean architecture也一起
這系列就是在講什麼時候該用什麼模式的準則
我這篇也講幾個重點原則
1. 保持簡單
能用最簡單的寫法
就用最簡單的寫法
初學SOLID和設計模式最常見的
就是手了拿了鎚子看什麼問題都是釘子
硬是要用只會過度設計
SOLID和設計模式是非到必要時刻不要使用
因為這東西是一把雙面刃
SOLID和設計模式的目的在於讓你未來更方便維護、擴充
但副作用是程式架構複雜化
一個弄不好反而更難維護
這就違反你當初使用這個招式的本意
2. 在有必要用的地方再用
承上題
所謂有必要用的地方
是指這個部份未來很有可能需要擴充或改動
如果你懂的基本的架構或OOP
你會自然而然把程式拆成好幾個小元件
每一個小元件都可以分成三種類型
第一種是未來極少會在改動
第二種是未來極可能會常常改動
第三種是當下不確定未來會不會改動
第一種就不要再去想設計模式
第二種你可以嘗試去加進設計模式
第三種比較有爭議
我個人是優先用單純的寫法
在未來真的遇到有改動時
我再重構
還是一樣
能不要用設計模式就不要用讓設計單純化
3. 正確模式的迷思
事實就是
沒有所謂的正確的模式
一百個問題會有一百種答案
一百個人也會有一百種選擇
但還是有個大原則可以依循
那就是先從最簡單的模式開始下手
做到一半發現不行不符合需求
再改成其它更複雜一點的模式
很有可能做完了想一想發現怎麼另一個模式更適合？
你再順手改成另一個模式
所以迭代演進才是重點
一次一次試
一次一次改
一次一次的重構
讓正確的模式在程式不斷演進之下慢慢成形
這個才是真正的使用到正確模式的唯一方法
而時間一久你會累積更多經驗
到時候你自然會進化成看到類似問題腦中自然出現模式的優先順序
大概就這三點
其實還有很多
書就自己去看吧
要玩這個就是這樣玩
會不會覺得
一定要搞這麼累嗎？
對就是要這麼累你才會進步
不然你也可以回去寫義大利麵程式也沒差
台灣不重視這個
寫程式寫了幾十年一個模式也不會SOLID完全沒概念的滿街都是
也不會怎樣啦