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. 總結

學設計模式不容易，需要熟悉語言、面向對象、理解設計原則。。。。即便是都看會了，理解了，到了應用又是個麻煩事兒。

有一位大牛說過：《設計模式》這本書，我們要像字典一樣經常拿出來翻翻看看，而不是通篇看完就算了。

可見，它需要我們長期的“學習 - 應用 - 總結 - 學習”，才能更好的理解。

另外，我感覺在系統設計中，也沒有必要非得去套用設計模式，只要符合設計原則，符合開發、運行效率，怎樣設計都行，不要為了用而用，濫用不如不用。

話又說回來，還是對設計大原則，對“道”的理解。