譯文來源：倪大蝦的部落格
簡介
自上篇翻譯《如何向妻子解釋OOD》後收到了很好的反應。故特繼續翻譯作者的《How I explained Design Patterns to my wife: Part 1》一文，以饗讀者。在此文中，作者依舊通過與妻子淺顯易懂的對話，向讀者解釋了什麼是設計模式。
設計模式是什麼?
Shubho:通過我們關於物件導向設計原則（OODP，即SOLID原則）的對話，我想你已經對物件導向設計原則（OODP）有了基本的認識。希望你不要介意我把對話分享到部落格上。你可以在這找到它：《如何向妻子解釋OOD》.
設計模式是這些原則在某些特定公共場景下標準化的應用，接下來讓我們通過一些例子學習什麼是設計模式。
Farhana: 當然，我喜歡例子。
Shubho: 讓我們以汽車為例討論一下。汽車是一個很複雜的物件，由成千上萬的其它物件組成，如發動機，車輪，方向盤，車座，車體等等其他不同的部分或部件。
汽車部件
當裝配汽車時，製造商需要集中並裝配這些更小的自成汽車子系統的不同部件。而這些不同的小部件同樣也是複雜的物件，其它製造商同樣要生產並組裝它們。在生產汽車時，汽車公司並不會為怎麼生產組裝這些部件操心（前提是他們要確保這些物件/裝置的質量）。當然，汽車製造商更加關心怎麼裝配這些不同部件以便能生產不同型號的汽車。
通過遵循不同的設計，組裝不同的部件，生產不同型號的汽車
Farhana: 汽車製造公司必須有如何生產不同型號汽車的設計圖或藍圖，對嗎？
Shubho: 當然，並且這些設計都是良好的，他們花費大量的時間和精力來做這些設計。一旦設計完成，生產汽車就僅僅是照葫蘆畫瓢了。
Farhana: 嗯。如果事先有一些好的設計，就能在短時間內遵照這些設計生產不同產品，並且製造商在每次生產某一個型號產品時就不需要重新設計或重新發明車輪，他們只需要按照已有的設計辦事就行了。
生產不同型號產品（汽車）的不同設計圖
Shubho: 你抓到重點了。現在假設我們是軟體生產商，我們使用基於需求而來的不同元件或功能構建各種不同的軟體程式。當生產這些不同軟體系統時，我們常常需要為一些不同軟體系統中存在的相同情況開發程式碼，對嗎？
Farhana: 是的，在開發不同軟體程式時經常遇到相同的設計問題。
Shubho: 我們嘗試使用物件導向的方式開發軟體，並嘗試應用OOPD來讓程式碼能易於維護，可複用，可擴充套件。無論什麼時候，當我們遇到這些設計問題時，如果我們有一組經過謹慎開發，良好測試的物件以供使用會不會更好呢？
Farhana: 是的，這樣能夠節省時間，生產出更好的軟體，且利於以後維護。
Shubho: 很好！從設計上來說，它的好處是你不需要開發那些物件。經過多年發展，人們已經遇到過一些類似的設計問題，並已經形成有一些公認的，良好的已標準化的設計方案。我們稱之為設計模式。
我們一定好感謝四人組，他們在《設計模式：可複用物件導向軟體設計》中總結出了23種基本的設計模式。四人組由Erich Gamma, Richard Helm, Ralph Johnson, 和John Vlissides組成。實際中有很多物件導向設計模式，但這23種模式被公認為是所有其他設計模式的基礎。
Farhana: 我能發明一個新的模式嗎？這可能嗎？
Shubho: 當然，親愛的，為什麼不能呢？！設計模式不是由科學家發明創造的。它們是被發現找到的。這意味著任何通用問題場景中都有一些好的設計方案在那。如果我們能夠指出一個能夠解決一個新的設計相關問題的物件導向設計，那麼這將會是一個由我們定義的新的設計模式。誰知道呢？！如果我們發現找到一些設計模式，或許將來有一天人們會稱我們為二人組，哈哈。
Fahana:
我們將如何學習設計模式？
Shubho: 我一直認為例子是學習的最好途徑。在我們的學習方法中，我們不會先討論理論後討論實現。我認為這是很糟糕的方式。設計模式不是基於理論的發明。事實上，問題場景首先出現，其次是基於這些問題的來龍去脈和需求，然後是一些設計方案的演化，最後其中的一些被標準化為模式。所以對每一個我們討論的設計模式，我們將嘗試理解並分析一些現實生活中的例子，然後一步步嘗試歸納一個設計，並最後總結一些與某些模式匹配設計。設計模式就是在這些相似過程中發現的。你認為呢？
Farhana:我想這種方式對我更有用。如果我能通過分析問題和歸納方案得出設計模式，我就不用死記那些設計模式和定義了。請按照你的方式繼續。
一個常見的設計問題和它的解決方案
Shubho: 讓我們考慮下面的場景：
我們房間裡有些電器（電燈，風扇等）。這些裝置按照某些方式佈局，並由開關控制。任何時候你都能替換或排查一個電器而不用碰到其他東西。例如，你可以換一個電燈而不需要換開關。同樣，你可以換一個開關或排查它而不需要碰到或替換相應的電燈或風扇；甚至你可以用把電燈連線到風扇的開關上，把風扇連到電燈的開關上，而不需要碰到開關。
電器：風扇和電燈
風扇和電燈的兩種不同開關，一個普通點，另一個別致點
Farhana: 是的，但就是這樣子，對嗎？
Shubho: 是的，確實如此，就該如此佈局。當不同東西聯絡在一起時，它們應該按照一定方式聯絡：修改或替換一個系統時不會影響到另一個，或者說即便有，也應該最小化。這能夠讓你的系統易於管理，且成本低。想想一下，如果改一下房間裡的燈同時需要改開關，你會樂意在你房子上花錢並安裝這個系統嗎？
Farhana: 當然不會。
Shubho: 現在，讓我們思考一下電燈或風扇如何連線到開關上才能達到改變一個不會影響到另一個。你認為該如何？
Farhana: 用電線!
Shubho: 很好。把電燈/風扇和開關聯絡到一起的是電線和電器佈局。我們可以它們看做不同系統間相互聯絡的橋樑。其基本的思想是，一個事物不能和另一外一個事物直接聯絡。當然啦，它們應當通過某些橋樑或介面聯絡在一起。用軟體術語來說，這叫“鬆耦合”。
Farhana: 我知道了。
Shubho: 現在，讓我們嘗試推斷在電燈/風扇和開關例子中的幾個關鍵問題，並嘗試推斷它們是如何設計並聯系起來的。
Farhana: 好，我們試一下。
例子中我們有開關，可能有幾種開關，如普通的開關，漂亮的開關，但通常來說它們還是開關，並且每種開關都能夠開啟和關閉。
所以下面我們會有一個開關基類Switch：
|
1 2 3 4 5 6 7 8 |
public class Switch { public void On() { //開啟開關 } public void Off() { //關閉開關 } } |
接下來我們可以有一些具體的開關，例如一個漂亮開關，一個普通開關等等，當然，我們會讓類FancySwitch和NormalSwitchnd繼承類Switch：
|
1 2 3 4 |
public class NormalSwitch : Switch { } public class FancySwitch : Switch { } |
這裡的兩個具體類有自己的特徵和行為，只是此時此刻，我們簡單化以下。
Shubho: 非常棒，接下來電燈和風扇怎麼辦？
Farhana: 我試試. 根據OODP的開放閉合原則，我們知道只要可能，就應該嘗試抽象，對嗎？
Shubho: 對
Farhana: 跟開關不一樣，風扇和電燈等是兩種不同的事物。對於開關，我們能夠使用一個開關基類Switch，但風扇和電燈是兩個不同的事物，相比定義一個基類，介面可能更合適。一般來說，他們都是電器。所以我們可以定義一個介面，如IElectricalEquipment，作為對電燈和風扇的抽象，可以嗎？
Shubho: 可以
Farhana: 好，每種電器都有些相同的功能。他們能夠開啟和關閉。所以介面可能如下：
|
1 2 3 4 |
public interface IElectricalEquipment { void PowerOn(); //每種電器都能開啟 void PowerOff(); //每種電器都能關閉 } |
Shubho: 太好了，你很善於抽象東西。現在我們需要一座橋樑。在現實中，電線是橋樑。在我們物件設計中，開關知道如何開啟和關閉電器，電器以某種方式聯絡到開關。這裡我們沒有電線，讓電器連線到開關的唯一方式是封裝。
Farhana: 是的，但開關不能直接知道風扇或電燈。開關應當知道一個電器IElectricalEquipment能夠開啟或關閉。這意味著，ISwitch應該有一個IElectricalEquipment例項，對嗎？
Shubho: 對，對風扇或電燈的封裝的例項是一個橋樑。所以讓我們修改Switch類以便封裝一個電器：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
public class Switch { public IElectricalEquipment equipment { get; set; } public void On() { //開關開啟 } public void Off() { //開關關閉 } } |
Farhana: 明白。讓我們定義真實的電器：風扇和電燈。如我所見，一般來說它們都是電器，所以它們都簡單實現了IElectricalEquipment介面。
下面是風扇類:
|
1 2 3 4 5 6 7 8 |
public class Fan : IElectricalEquipment { public void PowerOn() { Console.WriteLine("風扇開啟"); } public void PowerOff() { Console.WriteLine("風扇關閉"); } } |
下面是電燈類:
|
1 2 3 4 5 6 7 8 |
public class Light : IElectricalEquipment { public void PowerOn() { Console.WriteLine("電燈開啟"); } public void PowerOff() { Console.WriteLine("電燈關閉"); } } |
Shubho:太好了。現在讓開關工作。當開關開啟關閉的時候它應當能夠開啟關閉電器（它連線到的） 。
這裡的關鍵點是：
● 當開關按下開時，連線的電器也應該開啟。
● 當開關按下關時，連線的電器也應該關閉。
大致的程式碼如下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
static void Main(string[] args) { //構造電器裝置:風扇,開關 IElectricalEquipment fan = new Fan(); IElectricalEquipment light = new Light(); //構造開關 Switch fancySwitch = new FancySwitch(); Switch normalSwitch = new NormalSwitch(); //把風扇連線到開關 fancySwitch.equipment = fan; //開關連線到電器,那麼當開關開啟或關閉時電器應該開啟/關閉 fancySwitch.On(); fancySwitch.Off(); //把電燈連線到開關 fancySwitch.equipment = light; fancySwitch.On(); //開啟電燈 fancySwitch.Off(); //關閉電燈 } |
Farhana: 明白。開關的On()方法應當內部呼叫電器的TurnOn()方法，Off()方法應當內部呼叫TurnOff()方法，所以開關類Switch應如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
public class Switch { public IElectricalEquipment equipment { get; set; } public void On() { Console.WriteLine("開關開啟"); equipment.PowerOn(); } public void Off() { Console.WriteLine("開關關閉"); equipment.PowerOff(); } } |
Shubho: 很好。這自然允許你把風扇從一個開關接到另一個上。不過你看，反過來也可以。這意味著你可以改變風扇或電燈的開關而不需要碰到風扇或電燈。例如，你可以很輕鬆的把點燈的開關從FancySwitch換到NormalSwitch上，如下：
|
1 2 3 |
normalSwitch.equipment = light; normalSwitch.On(); //開啟電燈 normalSwitch.Off(); //關閉電燈 |
你看，連線一個抽象電器到一個開關（通過封裝）能夠讓你改變開關和電器而不會對對方產生影響。這個設計是優雅的，良好的。四人組為該模式取名為：橋接模式。
Farhana: 太棒了。我想我明白這個了。從根本上說，兩個系統不應當直接聯絡或依賴與對方。 當然，他們應該聯絡或依賴於抽象（如依賴倒置原則和開放閉合原則所講），所以他們是鬆耦合的，因此我們可以在需要時改變我們的實現而不會對系統其他部分產生過多影響。
Shubho: 你理解了，親愛的.我們看下橋接模式的定義：
“將抽象部分與實現部分分離，使它們都可以獨立的變化”
你看我們的實現完美遵循該定義。如果你有一個類設計器（如Visual Studio或其他支援該功能的IDE環境），你會看到類似的如下類圖：
橋接模式類圖
在這裡， Abstraction 是開關基類Switch。 RefinedAbstraction 是具體開關類 (FancySwitch, NormalSwitch 等等。)。 Implementor 是電器介面IElectricalEquipment。ConcreteImplementorA 和ConcreteImplementorB 是電燈類Light和風扇類Fan。
Farhana: 問你個問題，只是好奇啊。如你所說有很多其他的設計模式，為什麼你以橋接模式開始呢？有重要原因嗎？
Shubho: 這個問題很好。是的，我以橋接模式而不以其他開始是因為一個理由。我認為橋接模式是所有物件導向模式的基礎。理由如下：
● 它教導如何思考抽象，這是物件導向設計模式的關鍵概念。
●它實現了基本的OOD原則。
●它容易理解。
●如果正確理解該模式，學習其他模式會很容易。
Farhana: 你認為我理解的對嗎？
Shubho: 我認為你理解的非常正確。
Farhana: 那麼接下來是什麼？
Shubho: 通過理解橋接模式，我們僅僅是開始理解設計模式的思想。在我們接下的對話中，我們將會學習其他的設計模式，我希望你不會覺得它們無聊。
Farhana:不會的，相信我。