1. 前言
設計模式——最熟悉的陌生人。
很多人應該都有這種感受，早就知道設計模式，也能隨口說出幾種，但是不知道每種是怎麼回事。或者說只知道工廠模式等幾個常用，簡單的。估計那也是靠記憶，而不是真正的理解。
我也有這種親身體會，在好幾年之前就知道設計模式。之前也一直抽時間學，但總是學了就忘。而且學習過程很枯燥，完全是背誦式的記憶那些類圖，不是真正的理解，更別提應用了。
2. 關於“設計”
設計，就是為了更好的應對變化。沒畢業時候不知道軟體系統怎麼會有變化，但是工作之後慢慢就會發現，變化，那叫一個天馬行空。。。
一提到“設計”，大部分人可能會直接想到設計模式，而且是23種設計模式。其實這是錯誤的。其實學會設計、應用設計，應該分為四個層次：
2.1 物件導向
首先要了解物件導向，什麼是物件導向？什麼是封裝、繼承和多型，以及三個特點的表現形式。基礎很重要。
要想充分了解物件導向，三個特點，最好還是按部就班的參考一本權威書籍，看看書上說的你是不是真的理解。看看繼承和多型的表現形式你是否都知道。
如果沒按部就班看過書，就不要以為自己都會了。借用某相聲演員一句話：“你以為你以為的就是你以為的？”。。。
2.2 抽象與具體
如何更好的解決“變化”問題？答案是“提取抽象、隔離具體”。
什麼是“抽象”？ 抽象就是不變的東西，一個資料表的操作，總會有增刪改查，把他們作為介面，這是不變的。
什麼是“具體”？ 具體是實際執行的，一個資料表的增刪改查，用sqlserver、access還是oracle？可能會有變化。
我們應該依賴於抽象程式設計，而不是依賴於具體程式設計。應該把程式中的共性抽象出來，並且把具體實現的部分隔離開來，讓他們都依賴於抽象，並且互不影響。這其實就是設計。
只有理解了“抽象”、“具體”、“隔離”這幾個詞兒，你才能真正理解設計模式。否則就別指望。
2.3 SOLID五大原則
系統設計的5大原則，簡寫分別是S、O、L、I、D。
- S - 類職責單一原則： 即職責劃分要清晰，不同職責的不要攪和在一起。每個類應該只有一個讓他發生改變的原因。
- O - 開放封閉原則： 對擴充套件開發，對修改封閉。即如果系統要變化，就去擴充套件、新增新類，不要修改現有的類。
- L - LISKOV原則： 子類應該能充分覆蓋父類，並且讓使用者分不出差別。
- I - 介面分離原則：每個介面只管一個功能，不要出現“胖介面”。增加功能時，要加介面，而不是改介面
- D - 依賴倒置原則：具體應該依賴於抽象，而不是抽象一來於具體，即低層要依賴於高層。
對於以上5大原則，此處不詳細解釋，有興趣的可以查閱《你必須知道的.net》第二版，裡面講的非常詳細。
如果詳細分析這5大原則，其實他們都是圍繞著“提取抽象、隔離具體”來的。
- S - 類職責單一原則： 隔離
- O - 開放封閉原則： 依賴於抽象，隔離具體
- L - LISKOV原則：抽象
- I - 介面獨立原則：隔離
- D - 依賴倒置原則：依賴於抽象
2.4 設計模式
最後才是設計模式，設計模式其實是一些工具而已。
是“術”，不是“道”。如果你不明白以上那些“道”，而直接去學“術”，肯定是學一次忘一次。
在看每個設計模式的時候，你都要去向著這個方向去思考：它是不是提取了抽象、分離了具體、依賴於抽象、封裝了具體？ 這樣一來，你就會明白了。
3 例子：工廠模式
工廠模式在設計模式中分三種：簡單工廠、工廠方法和抽象工廠，其實這三種對應了不同的抽象程度。 下面簡單分析前兩種。
3.1 簡單工廠：
看上圖，很明顯是“提取抽象，分離具體”。將資料操作的介面提取出來，交給不同的實現類來實現。
工廠類返回的是IDBHelper介面，即客戶端會呼叫IDBHelper介面，而不需要關心具體實現，這就是“依賴於抽象，而不是依賴於具體”。
還符合“開放封閉原則”，例如現在又要用DB2資料庫，那麼再加一個實現類就行，無需改其他地方。客戶端也不會察覺後臺的變化。這就是：對擴充套件開放，對修改封閉。
簡單工廠之所以叫“簡單”，是因為它的工廠類還依賴於資料操作實現類，這違反了“依賴倒置原則”，那麼該怎麼辦呢？
3.2 工廠方法：
上文說了，簡單工廠類依賴與資料操作實現類，當前有3個實現類，那麼工廠類肯定需要判斷，免不了有if else或者swicth case語句，
switch (type) { case "sqlserver": return new SQLDBHelper(); case "oracle": return new OracleDBHelper(); case "access": return new AccessDBHelper(); default: throw new Exception("type引數錯誤"); }
而這些語句，就是設計模式重點要改進的地方。
如何讓工廠類不依賴於資料操作實現類？ 答案還是“提取抽象，分離具體實現”。
將工廠類的具體職責抽象出來，然後分離一些實現類，分別實現各自的功能。
4. 總結
學設計模式不容易，需要熟悉語言、物件導向、理解設計原則。。。。即便是都看會了，理解了，到了應用又是個麻煩事兒。
有一位大牛說過：《設計模式》這本書，我們要像字典一樣經常拿出來翻翻看看，而不是通篇看完就算了。
可見，它需要我們長期的“學習 - 應用 - 總結 - 學習”，才能更好的理解。
另外，我感覺在系統設計中，也沒有必要非得去套用設計模式，只要符合設計原則，符合開發、執行效率，怎樣設計都行，不要為了用而用，濫用不如不用。
話又說回來，還是對設計大原則，對“道”的理解。