引子

我跟媳婦曾經就面向對象設計這個話題做過有趣的探討。當我把它們發表在社區之后，得到了一些很不錯的反饋，也大大鼓舞了我。所以，我很高興能把我們后面的一次談話繼續分享出來，那是關于面向對象的設計模式的，大家往下看吧。

什么是設計模式

丈夫:?我想你現在對面向對象的設計原則有了一些基本概念了吧。我們那次關于OOD原則（SOLID原則）的有趣談話被我發表在社區上了，你不會介意吧？網址在這里:?我怎么向妻子解釋OOD。

設計模式則是這些原則在某些特定和常用條件下的應用，并且做了一些標準化。我們還是來一些例子吧。

媳婦:?好極了，我喜歡例子。

丈夫:?以我們的車為例吧。它是一個對象，不過有點復雜，是由幾千個其它對象組成的，包括引擎、車輪、轉向裝置、座位、車身，等等。

一輛車的各種零件。

這輛車在制造的時候，制造商收集所有的零件，把它們組裝起來。這些零件本身也是復雜的對象，是由其它的制造商組裝的。但汽車公司并不關心這些零件是怎么造出來的（當然，他們需要確信這些零件的質量是過硬的）。他們只會關心如何通過不同的方式將不同的零件組裝起來，以便生產出不同型號的汽車。

由不同零件根據不同設計組裝成的不同型號的車。

媳婦:?每種型號的汽車應該都有各自的設計和藍圖什么的，是吧？

丈夫:?非常正確。而且，這些設計是經過深思熟慮的，花了很長的時間和很大的努力才得以誕生。完成設計之后，汽車的生產就只剩下遵循設計這么簡單的事了。

媳婦:?嗯……很不錯的辦法，先想出一些優秀的設計，然后遵照這些設計，就可以在很短的時間里造出不同的東西。如果制造商想要開發某種型號的產品，不需要從頭進行設計，或者說重新造輪子，只要遵循那些設計就可以了。

用于不同型號產品（車）的不同設計。

丈夫:?你說到點子上了。現在，回到現實里，我們是軟件廠商，我們需要根據需求，用不同的組件來創造出不同的軟件。在這個過程中，一定會碰到一些情形，是在許多不同的軟件里都有的，對不對？

媳婦:?對啊。而且，我們還常常在不同的軟件里碰到相同的設計難題呢。

丈夫: 我們嘗試著用一種面向對象的方式來開發我們的軟件，利用OOD原則來讓我們的代碼更容易管理、重用和擴展。就像你上面提到的那些相同的問題，如果我們預先就有一些良好的設計，那是不是很棒呢？

媳婦: 是啊，那可以省下大把的時間，而且這樣打造的軟件質量更好，更容易管理。

丈夫: 沒錯。還有個好消息，我們并不需要自己造輪子。這么多年以來，遭遇同樣問題的人們早已發現了許多很棒的解決方案，而且把它們標準化過了。我們管這些方案叫設計模式。

我們要感謝四人幫(GoF)，他們在設計模式: 可重用面向對象軟件的基本元素這本書里歸納了23個最基本的設計模式。想知道這四個牛人是誰嗎？Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides。面向對象的設計模式很多，但大家認為這23個模式是其它模式的基礎。

媳婦：我能創建一個新模式嗎？有可能嗎？

丈夫：當然可以，親愛的，為什么不行呢？設計模式并不是被科學家發明和創造的東西。他們只是被“發現”而已。也就是說，對任何一個普通的問題場景，肯定會有一些好的設計方案。如果我們能識別出一個能解決某個新問題的面向對象設計，那我們就定義了一個新的設計模式。誰知道呢？如果我們發現一些設計模式，沒準兒大家會叫我們“二人幫”呢...哈哈。

媳婦：:)

我們怎么來學習設計模式呢？

丈夫: 我始終堅信，通過例子學習是最好的。在我們的學習過程中，我們不會“先理論后實踐”，因為我認為這是一種“壞”方法。設計模式不是基于理論發明的。相反，總是先有問題場景，再基于需求和情景不斷演化設計方案，最后把一些方案標準化成“模式”。所以，我們討論每一個設計模式時，要盡量用生活中的真實問題來理解和分析。然后嘗試一步步地闡述設計，并以一個能匹配某些模式的設計收尾。設計模式就是這樣被發現的，你覺得呢？

媳婦: 我覺得對我來說，這種方式可能更好使。如果我能通過先分析問題，然后闡述解決方案, 最后得到一個設計模式，我就不用死記那些圖形和定義了。就這么辦吧。

基礎的設計問題和解決方案

丈夫:?讓我們考慮一下下面的情況:

我們的家里都有家用電器（比如電燈和風扇），他們都是由開關控制。?任何時候，你都可以在不改變其他東西的情況下做一些事。你可以在不更換開關的情況下換掉燈泡，也可以在不接觸燈泡或者風扇的情況下更換開關，甚至可以在不接觸開關的情況下，把燈泡和風扇的開關互換。

媳婦：對啊，這看起來很自然，不是嗎？

丈夫：是的，非常自然，同時也應該這樣安排。當不同的事物聯系到一起時，他們應該在一個可以變更或者可以替換的系統中以便不相互影響，或者影響盡可能的小。這樣讓你更為方便、成本最小地去管理你的系統。可以想象，如果你要換一個你房間里的燈泡得要求你把開關也換了，你會考慮在你房子里使用這樣的一個系統嗎？

媳婦：當然不會。

丈夫：現在，讓我們想一下電燈或者電風扇是怎樣和開關聯系起來以便更換其中一個而不會影響到其他的。你想到什么了？

媳婦：當然是電線啦。

丈夫：正確，是電線以及其他的電工手段把電燈/電風扇與開關連接起來。我們可以把這概括為溝通不同系統的橋梁。基本思想是，一個事物不能直接連接另一個事物。當然，他們能夠通過一些橋梁或接口連接起來。在軟件世界里，我們稱之為“松耦合”。

媳婦：嗯，我明白這點。

丈夫：現在，我們來嘗試理解一些類似電燈/電風扇與開關類似的關鍵問題，同時嘗試理解是怎樣設計和關聯它們的。

媳婦：好的，我們開始吧。

在我們的列子里，有一些開關，這些類似普通的開關、有不同的花式開關可能有不同的種類，但是，一般情況下，他們就是開關。同時，每個開關都能開和關。

同時，我們可能也 需要一些特定類型的開關，譬如正常的開關、不同花式的開關等等。同樣的我們擴展Switch類來實現FancySwitch和NormalSwitch：

這兩個特定的開關類可能用于它們自己特有的行為和特征，但是到目前為止，我們還是保持它們現在的簡單形式。

丈夫：棒極了。現在，如何處理風扇和燈呢？

媳婦：讓我試試。按照面向對象設計原則中的封閉原則，我認為我們需要試著在任何可能的地方做抽象處理，對嗎？

丈夫：對。

媳婦: 電扇和電燈情況有點不一樣，它們兩個不是同一種東西。對于不同的開關，我們可以用同一個基本的Switch類，但對于電扇和電燈就不大合適了，感覺用接口會更合適一點。因為，從大體上講，它們都算是電器，那么我們可以就定義一個接口: IElectricalEquipment，用它來抽象電扇和電燈，對不對？

丈夫:?很對。

媳婦:?那么，所有電器都有一些共性，可以被打開和關閉。那么這個接口就可以是:

媳婦: 沒錯，開關并不知道電扇和電燈的存在。它只知道它可以打開或關閉某個電器IElectricalEquipment。那么，也就是說每個Switch應該擁有一個IElectricalEquipment實例，是吧？

丈夫:?很對。這里，被封裝的實例，也就是IElectricalEquipment，就是這座橋。好，我們來修改一下Switch類，讓它把電器封裝進去:

電扇類:

電燈類:

也就是說:

• 當按下開關的打開按鈕時，必須打開連接的電器。
• 當按下開關的關閉按鈕時，必須關閉連接的電器。

我們想要的功能基本上是這個樣子:

丈夫: 干得好。這個電扇顯示是可以換開關的。而且，反過來也是可以換的，可以不修改電扇和電燈，直接更換開關，例如，我們可以把電燈的開關從FancySwitch換成NormalSwitch:

媳婦：酷！我懂了。一般來說，兩個系統不應該直接地互相聯接和依賴。相反，他們應該通過抽象來聯接或依賴（正如依賴倒置和開閉原則所言），這樣它們就是松耦合的，我們就可以在必要時輕松地修改實現，而不對系統的其它部分造成太大影響。

我：親愛的，你得我真傳了。我們來看一下橋接模式的定義吧：

“把抽象和實現解耦，使得它們可以獨立地變化”

我們的設計完全符合定義。如果你有類設計器（Visual Studio和其它流行的IDE都有這功能），你能看到一個和下圖相似的類圖：

在我們的例子里，Abstraction是基礎的Switch類，RefinedAbstraction是某個具體的開關類（FancySwitch和NormalSwitch），Implementor是IElectricalEquipment接口，ConcreteImplementorA和ConcreteImplementorB分別是Fan和Light類。

媳婦: 我有點好奇。你不是說有很多模式么，干嘛先說橋梁模式呢？有什么特別重要的原因嗎？

丈夫: 問得好。我從橋梁模式開始，而不是其它模式，只有一個原因。我覺得它是所有面向對象設計模式的基礎。因為:

• 它能教你如何抽象地思維，這可是OO設計模式的關鍵。
• 它實現了基本的OOD原則。
• 它很好理解。
• 如果你能正確地理解它，學習其它模式就易如反掌了。

媳婦:?你覺得我理解的對么？

丈夫: 哦~親愛的，我覺得你理解的非常好。

媳婦:?那么，下一步呢？

丈夫:?通過了解橋接模式，我們才稍微的了解了設計模式的概念。在我們接下來的談話中，我們將會學習其他的涉及模式，希望你不會覺得它們無聊。

媳婦:?不會的，相信我。

Next