源自：http://www.cnblogs.com/niyw/archive/2011/05/30/2062071.html
簡介
自上篇翻譯<如何向妻子解釋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: :)
我們将如何學習設計模式？
我一直認為例子是學習的最好途徑。在我們的學習方法中，我們不會先讨論理論後讨論實作。我認為這是很糟糕的方式。設計模式不是基于理論的發明。事實上，問
題場景首先出現，其次是基于這些問題的來龍去脈和需求，然後是一些設計方案的演化，最後其中的一些被标準化為模式。是以對每一個我們讨論的設計模式，我們
将嘗試了解并分析一些現實生活中的例子，然後一步步嘗試歸納一個設計，并最後總結一些與某些模式比對設計。設計模式就是在這些相似過程中發現的。你認為
呢？
Farhana:我想這種方式對我更有用。如果我能通過分析問題和歸納方案得出設計模式，我就不用死記那些設計模式和定義了。請按照你的方式繼續。
一個常見的設計問題和它的解決方案
Shubho: 讓我們考慮下面的場景：
我們房間裡有些電器（電燈，風扇等）。這些裝置按照某些方式布局，并由開關控制。任何時候你都能替換或排查一個電器而不用碰到其他東西。例如，你可
以換一個電燈而不需要換開關。同樣，你可以換一個開關或排查它而不需要碰到或替換相應的電燈或風扇；甚至你可以用把電燈連接配接到風扇的開關上，把風扇連到電
燈的開關上，而不需要碰到開關。
電器：風扇和電燈
風扇和電燈的兩種不同開關，一個普通點，另一個别緻點
Farhana: 是的，但就是這樣子，對嗎？
是的，确實如此，就該如此布局。當不同東西聯系在一起時，它們應該按照一定方式聯系：修改或替換一個系統時不會影響到另一個，或者說即便有，也應該最小
化。這能夠讓你的系統易于管理，且成本低。想想一下，如果改一下房間裡的燈同時需要改開關，你會樂意在你房子上花錢并安裝這個系統嗎？
Farhana: 當然不會。
Shubho: 現在，讓我們思考一下電燈或風扇如何連接配接到開關上才能達到改變一個不會影響到另一個。你認為該如何？
Farhana: 用電線!
Shubho: 很好。把電燈/風扇和開關聯系到一起的是電線和電器布局。我們可以它們看做不同系統間互相聯系的橋梁。其基本的思想是，一個事物不能和另一外一個事物直接聯系。當然啦，它們應當通過某些橋梁或接口聯系在一起。用軟體術語來說，這叫“松耦合”。
Farhana: 我知道了。
Shubho: 現在，讓我們嘗試推斷在電燈/風扇和開關例子中的幾個關鍵問題，并嘗試推斷它們是如何設計并聯系起來的。
Farhana: 好，我們試一下。
例子中我們有開關，可能有幾種開關，如普通的開關，漂亮的開關，但通常來說它們還是開關，并且每種開關都能夠打開和關閉。
是以下面我們會有一個開關基類Switch：
public class Switch {
public void On() {
//打開開關
}
public void Off() {
//關閉開關
}
接下來我們可以有一些具體的開關，例如一個漂亮開關，一個普通開關等等，當然，
我們會讓類FancySwitch和
NormalSwitch
nd繼承類
Switch：
public class NormalSwitch : Switch {
public class FancySwitch : Switch {
這裡的兩個具體類有自己的特征和行為，隻是此時此刻，我們簡單化以下。
Shubho: 非常棒，接下來電燈和風扇怎麼辦？
Farhana: 我試試. 根據OODP的開放閉合原則，我們知道隻要可能，就應該嘗試抽象，對嗎？
Shubho: 對
Farhana: 跟開關不一樣，風扇和電燈等是兩種不同的事物。對于開關，我們能夠使用一個開關基類
Switch
，但風扇和電燈是兩個不同的事物，相比定義一個基類，接口可能更合适。一般來說，他們都是電器。是以我們可以定義一個接口，如
IElectricalEquipment，作為對電燈和風扇的抽象，可以嗎？
Shubho: 可以
Farhana: 好，每種電器都有些相同的功能。他們能夠打開和關閉。是以接口可能如下：
public interface IElectricalEquipment {
void PowerOn(); //每種電器都能打開
void PowerOff(); //每種電器都能關閉
Shubho: 太好了，你很善于抽象東西。現在我們需要一座橋梁。在現實中，電線是橋梁。在我們對象設計中，開關知道如何打開和關閉電器，電器以某種方式聯系到開關。這裡我們沒有電線，讓電器連接配接到開關的唯一方式是封裝。
Farhana: 是的，但開關不能直接知道風扇或電燈。開關應當知道一個電器
IElectricalEquipment能夠打開或關閉。這意味着，
ISwitch
應該有一個
IElectricalEquipment執行個體，對嗎？
Shubho: 對，對風扇或電燈的封裝的執行個體是一個橋梁。是以讓我們修改
Switch類以便封裝一個電器：
public IElectricalEquipment equipment {
get;
set;
//開關打開
//開關關閉
Farhana: 明白。讓我們定義真實的電器：風扇和電燈。如我所見，一般來說它們都是電器，是以它們都簡單實作了
IElectricalEquipment
接口。
下面是風扇類:
public class Fan : IElectricalEquipment {
public void PowerOn() {
Console.WriteLine("風扇打開");
public void PowerOff() {
Console.WriteLine("風扇關閉");
下面是電燈類:
public class Light : IElectricalEquipment {
Console.WriteLine("電燈打開");
Console.WriteLine("電燈關閉");
Shubho:太好了。現在讓開關工作。當開關打開關閉的時候它應當能夠打開關閉電器（它連接配接到的） 。
這裡的關鍵點是：
- 當開關按下開時，連接配接的電器也應該打開。
- 當開關按下關時，連接配接的電器也應該關閉。
大緻的代碼如下:
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應如下：
Console.WriteLine("開關打開");
equipment.PowerOn();
Console.WriteLine("開關關閉");
equipment.PowerOff();
Shubho: 很好。這自然允許你把風扇從一個開關接到另一個上。不過你看，反過來也可以。這意味着你可以改變風扇或電燈的開關而不需要碰到風扇或電燈。例如，你可以很輕松的把點燈的開關從FancySwitch換到NormalSwitch上，如下：
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: 那麼接下來是什麼？