看老外程序員如何向妻子解釋設計模式
設計模式是什么?
Shubho:通過我們關于面向對象設計原則(OODP，即SOLID原則)的對話，我想你已經對面向對象設計原則(OODP)有了基本的認識。希望你不要介意我把對話分享到博客上。你可以在這找到它：<如何向妻子解釋OOD>.
設計模式是這些原則在某些特定公共場景下標準化的應用，接下來讓我們通過一些例子學習什么是設計模式。
Farhana: 當然，我喜歡例子。
Shubho: 讓我們以汽車為例討論一下。汽車是一個很復雜的對象，由成千上萬的其它對象組成，如發動機，車輪，方向盤，車座，車體等等其他不同的部分或部件。
汽車部件
當裝配汽車時，制造商需要集中并裝配這些更小的自成汽車子系統的不同部件。而這些不同的小部件同樣也是復雜的對象，其它制造商同樣要生產并組裝它們。在生產汽車時，汽車公司并不會為怎么生產組裝這些部件操心(前提是他們要確保這些對象/設備的質量)。當然，汽車制造商更加關心怎么裝配這些不同部件以便能生產不同型號的汽車。
通過遵循不同的設計，組裝不同的部件，生產不同型號的汽車
Farhana: 汽車制造公司必須有如何生產不同型號汽車的設計圖或藍圖，對嗎?
Shubho: 當然，并且這些設計都是良好的，他們花費大量的時間和精力來做這些設計。一旦設計完成，生產汽車就僅僅是照葫蘆畫瓢了。
Farhana: 嗯。如果事先有一些好的設計，就能在短時間內遵照這些設計生產不同產品，并且制造商在每次生產某一個型號產品時就不需要重新設計或重新發明車輪，他們只需要按照已有的設計辦事就行了。
生產不同型號產品(汽車)的不同設計圖
Shubho: 你抓到重點了?，F在假設我們是軟件生產商，我們使用基于需求而來的不同組件或功能構建各種不同的軟件程序。當生產這些不同軟件系統時，我們常常需要為一些不同軟件系統中存在的相同情況開發代碼，對嗎?
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: 好，我們試一下。
例子中我們有開關，可能有幾種開關，如普通的開關，漂亮的開關，但通常來說它們還是開關，并且每種開關都能夠打開和關閉。
#p#
所以下面我們會有一個開關基類Switch：
- public class Switch {
- public void On()
- { //打開開關 }
- public void Off()
- { //關閉開關 }
- }
接下來我們可以有一些具體的開關，例如一個漂亮開關，一個普通開關等等，當然，我們會讓類FancySwitch和NormalSwitchnd繼承類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: 太好了，你很善于抽象東西?，F在我們需要一座橋梁。在現實中，電線是橋梁。在我們對象設計中，開關知道如何打開和關閉電器，電器以某種方式聯系到開關。這里我們沒有電線，讓電器連接到開關的唯一方式是封裝。
Farhana: 是的，但開關不能直接知道風扇或電燈。開關應當知道一個電器IElectricalEquipment能夠打開或關閉。這意味著，ISwitch應該有一個IElectricalEquipment實例，對嗎?
Shubho: 對，對風扇或電燈的封裝的實例是一個橋梁。所以讓我們修改Switch類以便封裝一個電器：
- public class Switch {
- public IElectricalEquipment equipment {
- get;
- set;
- }
- public void On() {
- //開關打開
- }
- public void Off() {
- //開關關閉
- }
- }
Farhana: 明白。讓我們定義真實的電器：風扇和電燈。如我所見，一般來說它們都是電器，所以它們都簡單實現了IElectricalEquipment接口。
下面是風扇類:
- public class Fan : IElectricalEquipment {
- public void PowerOn() {
- Console.WriteLine("風扇打開");
- }
- public void PowerOff() {
- Console.WriteLine("風扇關閉");
- }
- }
下面是電燈類:
- public class Light : IElectricalEquipment {
- public void PowerOn() {
- Console.WriteLine("電燈打開");
- }
- public void PowerOff() {
- Console.WriteLine("電燈關閉");
- }
- }
Shubho:太好了。現在讓開關工作。當開關打開關閉的時候它應當能夠打開關閉電器(它連接到的) 。
這里的關鍵點是：
當開關按下開時，連接的電器也應該打開。
當開關按下關時，連接的電器也應該關閉。
大致的代碼如下:
- static void Main(string[] args) {
- //構造電器設備:風扇,開關
- IElectricalEquipment fan = new Fan();
- IElectricalEquipment light = new Light();
- //構造開關
- Switch fancySwitch = new FancySwitch();
- Switch normalSwitch = new NormalSwitch();
- //把風扇連接到開關
- fanfancySwitch.equipment = fan;
- //開關連接到電器,那么當開關打開或關閉時電器應該打開/關閉
- fancySwitch.On();
- fancySwitch.Off();
- //把電燈連接到開關
- fancySwitch.equipment = light;
- fancySwitch.On(); //打開電燈
- fancySwitch.Off(); //關閉電燈
- }
Farhana: 明白。開關的On()方法應當內部調用電器的TurnOn()方法，Off()方法應當內部調用TurnOff()方法，所以開關類Switch應如下：
- 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上，如下：
- 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:不會的，相信我。
原文鏈接：http://www.cnblogs.com/niyw/archive/2011/05/30/2062071.html
【編輯推薦】
