設計模式 what? why? how?

什麼是設計模式?

模式是在一定場景下,針對某些問題的某些解決方案.

軟體開發的過程中,總是遇到一系列相似的問題,比如,演算法需要被其他同類演算法代替,某個介面需要轉換成要求的介面,建立不同物件的組合,對於這些我們經常遇到的問題,有人根據實踐和經驗總結出一套普遍適用的解決方法(上面對應策略模式,介面卡模式,抽象工廠).

為什麼要使用設計模式?

首先沒有模式,我們也可以完成工作,不適用抽象工廠,我們可以加條件判斷要依賴哪些類,並逐個用 new 例項化.那為什麼還要使用模式呢?

使用設計模式的目的,是為了使軟體更從從容地應對變化.具體體現在,儘可能小範圍地改動程式碼,注意,不是更少地寫程式碼,引入模式有可能會讓我們寫更多的程式碼(比如命令模式和狀態模式).

儘可能小,意味著,程式碼只需要在一個或者幾個特定的類中做更改,或者只需要新增幾個相似的類,而不是分散地感覺混亂地對程式碼各處做修改.

簡而言之,設計模式將變化封裝起來,使得改變更容易被控制.

(記得我畢業找的第一份工作,公司做的產品是一個監控平臺,要相容不同廠商的 SDK,不同廠商 SDK 介面差別有大有小,以前寫程式碼的人也不怎麼懂設計模式,結果就是,有時要新增一個新型號裝置,或者升級一下 SDK,要從不同檔案不同方法做 n 處修改.現在我還經常回憶起那個長達8000行的方法,裡面巢狀了 n 層 switch,找個匹配的括號都是如此困難…)

什麼時候使用設計模式?

我認為有以下兩個情景該考慮用設計模式.

1. 假如在做設計的時候明確知道未來的變化(而不是靠猜測),那你就應該用設計模式將變化的部分封裝起來.
2. 假如你正在重構程式碼,那麼你應該考慮將導致系統醜陋的程式碼(那通常就是始料未及的變化),並也要顧及到將來會變化的程式碼,應用某些設計模式,使得模組或者系統當前的程式碼變得整潔,也能夠兼顧將來的變化.

什麼時候不應該使用設計模式?

不知道將來明確的變化,只是憑藉自己的假象,這時應該放棄應用設計模式的衝動.

當前系統已經足夠複雜,不想繼續擴充其功能,這時應該儘量少對程式碼進行重構,意圖是儘量少地容納將來的變化,以免使系統無法維護.

如何應用設計模式?

當你確定自己需要用設計模式,並覺得此處應該用某個模式會解決你的問題,你應該在對照一下這個列表,再考慮一下:

• 你的場景是否與此模式的應用場景吻合.
• 你期望的結果是否與此模式的意圖相吻合.
• 你是否要對這個模式做一些修改,使得模式更適用你的場景.
• 結合業務場景,確定模式的參與者及他們的協作關係(比如,觀察者模式,哪些類會被作為主題,哪些類是觀察者).
• 當前使用的語言,在實現這個模式是不是有值得注意的地方(比如單例模式中的併發問題).