換種思路去理解設計模式（上）

本文轉載自查看原文 2014-05-23 20:04 9928 設計/ 設計模式

1 前言

　　看過許多關於設計模式的博客，也讀過關於設計模式的書。幾乎所有的介紹的開頭，直接就引入了“設計模式”或者“某某模式”。設計模式到底是因什么而來？這是一個很重要的問題。孫悟空從石頭縫里蹦出來，《西游記》還介紹了這個石頭的來歷呢。

　　要想了解一個東西，至少有“3W”——what、why、how——是什么、為什么、怎么用。看現在大部分的文章或者書籍，重點介紹的還是“what”，這就有點類似於：為了用設計模式用設計模式。在這種思想的教導下去了解設計模式，學不會也很正常。

另外，介紹一個東西的用處時，不要弄一些小貓小狗、肯德基、打籃球、追MM這話總例子。這就像用小學課本的兒童故事來給你講解一個人生道理一樣，你聽着明白，但是真能理解嗎？

2 概述

　　記得之前看過一篇博客，具體內容現在都忘記了。記得上面有句話大體是什么說的：所謂的設計模式，我們日常工作中經常用，只是我們沒有想過像GoF一樣，把這些日常用到的模式總結歸納，形成結構化的理論。

　　可見，設計模式不真正是GoF提出的概念，而是他們作為一個有心人，把人們日常工作中遇到的設計問題，全面的總結，才形成了之后的“23種設計模式”。

　　首先，設計模式解決的肯定是系統設計問題，而且會用到面向對象來解決的。所以，本書開頭先說設計原則和面向對象。面向對象基礎知識，大部分人應該都了解；至於設計原則，不了解的人必須要先了解。

　　其次，我們將模擬一個簡單的對象聲明周期過程，從對象的創建、封裝、組合、執行和操作，一步一步走來，會遇到許多情況和問題。針對問題，我們將通過思考，利用面向對象和設計原則，解決這個問題。而解決這個問題的方法，便是一種設計模式。

　　最后，23種設計模式不是一盤散沙，是有關系的。就是對象的生命周期一步一步的將各個設計模式串聯在了一起。對象的生命周期中，會一步一步的遇到總共23種設計問題，所以才會有23種設計模式。

3 設計原則

　　設計模式解決的肯定是系統設計的問題，所以首先從“設計”說起。

　　設計所要解決的主要問題，是如何高效率、高質量、低風險的應對各種各類變化，例如需求變更、軟件升級等。設計的方式主要是提取抽象、隔離變化，有5大設計原則——“SOLID”，具體體現了這個思路。

S - 單一職責原則：

　　一個類只能有一個讓它變化的原因。即，將不同的功能隔離開來，不要都混合到一個類中。

O - 開放封閉原則：

　　對擴展開放，對修改封閉。即，如果遇到需求變化，要通過添加新的類來實現，而不是修改現有的代碼。這一點也符合單一職責原則。

L - Liskov原則：

　　子類可以完全覆蓋父類。

I - 接口隔離原則：

　　每個接口都實現單一的功能。添加新功能時，要增加一個新接口，而不是修改已有的接口，禁止出現“胖接口”。符合單一職責原則和開放封閉原則。

D – 依賴倒置原則：

　　具體依賴於抽象，而非抽象依賴與具體。即，要把不同子類的相同功能抽象出來，依賴與這個抽象，而不是依賴於具體的子類。

　　總結這些設計原則可知，設計最終關注的還是“抽象”和“隔離”。面向對象的封裝、繼承和多態，還有每個設計模式，分析它們都離不開這兩個詞。

4 面向對象基礎

　　繼承、封裝、多態

　　接口、抽象類

5 一個對象的生命周期

　　一個對象在系統中的生命周期可以概括為以下幾點：

對象創建：

　　想到對象創建，最多的就是通過new一個類型來創建對象。但也會有許多特殊的情況，例如對象創建過程很復雜，如何解耦？等等。

對象組合、包裝：

　　一個對象創建后，可能需要對其就行包裝或者封裝，還可能由多個對象組成一個組合結構。在這過程中，也會遇到各種問題。

對象操作：

　　對象創建了，也組合、包裝完畢，然后就需要執行對象的各種操作，這是對象真正起作用的階段。對象的操作情況眾多，問題也很多。

對象消亡：

　　直到最后對象消亡，在C#中將被GC回收。

　　以上簡單介紹這個過程，其中的具體描述以及遇到的情況和問題，會在下文中詳細講解

6 創建一個對象

6.1 過程描述

一般對象的創建可以new一個類型，相信系統中絕大部分的對象創建也是這么做的。但是如果遇到以下情況，直接用new一個類型，會遇到各種各樣的問題。

6.2 情況1：拷貝創建

　　系統中肯定會遇到這種情況，新建對象時，要用到一個現有對象的許多屬性、方法等。這時候再通過new一個新的空對象，還需要把這些屬性、方法都賦值到新對象中，帶來不必要的工作量。

　　提出這個問題，我們會想到克隆，也可能已經在系統中用到了克隆。其實這個就是一個比較簡單的設計模式——原型模式。我們把這個“克隆”動作抽象到一個接口中，需要克隆的類型，實現這個接口即可。

C#已經在FCL（Framework Class Library）中定義了一個接口——IColoneable，因此不需要我們在自己定義該接口，只需要在用到的地方實現即可。IColoneable接口只定義了一個Colone方法：

　　例如FCL中的String類，實現了IColoneable接口，並實現了接口方法Colone()。

6.3 情況2：限制單一對象

　　如果一個對象定義的屬性和方法，可供系統的所有模塊使用，例如系統的一些配置項。此時無需再去創建多個對象。也不允許用戶創建多個對象，因為一旦修改，只修改這一個對象，系統的所有模塊都將生效。

　　我們把這個只能實例化一次的對象叫做“單例”，這種模式叫做單例模式。

　　其實系統中的靜態類，就是這種“單例”的設計思想。例如FCL中的Console類，它是一個靜態類，它給系統提供的就是一個“單例”類。

　　只不過Console是一個類型，而不是對象，缺點就是無法作為對象賦值和傳遞。如果系統中需要的“單例”就是一些功能，涉及不到對象的賦值和傳遞，完全可以用靜態類實現，沒必要非得用單例對象。

　　對象的單例模式，關鍵在於限制類型的構造函數，不讓使用者隨意new一個新對象，且看代碼：

　　重點：將構造函數設置為private，只能內部調用；用一個靜態字段來存儲對象。

　　可見，無論單例是類型還是對象，都需要通過“靜態”來實現。

6.4 情況3：復雜對象

　　創建一個新對象時，一般需要初始化對象的一些屬性。簡單的初始化可以用通過構造函數和直接賦值來完成。

　　但是如果一個對象的屬性過多，業務邏輯很復雜，就會導致復雜的創建過程。這種情況下，用構造函數是不好解決的。如果用直接賦值，就會導致大量的if…else…或者switch…case...的條件判斷。這樣的代碼將給系統的維護和擴展帶來不便，而且如果不改變設計，會隨着維護和擴展，會出現更多的條件判斷。隨着代碼量的增加，維護難度更大。如果再是多人同時維護，那就麻煩了。

　　顯然，這樣的代碼不是我們所期望的。設計上也不符合單一指責原則、開放封閉原則。所以，對於一個復雜對象的創建過程，我們將考慮重構。

　　我們把對象創建的過程抽象出來，做成一個框架，然后派生不同的子類，來實現不同的配置。將復雜對象的構建與其表示分離，這就是建造者模式。

　　上圖中，我們最終要創建的是Product類型的對象，Product是個復雜對象。如果直接new一個對象，再賦值，會導致大量條件判斷。

　　所以，我們將對象創建過程抽象到一個Builder抽象類中，然后用不同的子類去實現具體的對象創建。這樣的設計相比之前大量的if-else-代碼，優勢是非常明顯的，並且符合單一職責原則和開放封閉原則。應對需求變更、新功能增加、多人協同開發都是有好處的。

6.5 情況4：功能相同的對象

　　最經典的就是數據操作。創建一個用於SQL server的SQLDBHelper類，又創建了一個用於Oracle的OracleDBHelper類，這兩個類所實現的功能是完全一樣的，都是增刪改查等。如果這兩個類是孤立的，那系統數據庫切換時候，將導致SQLDBHelper和OracleDBHelper兩個類之間的切換，而且改動工作量隨着系統復雜度增加。