程式設計思想┊從執行個體談面向對象程式設計(OOP)、工廠模式和重構

有了翅膀才能飛，欠缺靈活的代碼就象凍壞了翅膀的鳥兒。不能飛翔，就少了幾許靈動的氣韻。我們需要給代碼帶去溫暖的陽光，讓僵冷的翅膀重新飛起來。結合執行個體，通過應用OOP、設計模式和重構，你會看到代碼是怎樣一步一步複活的。

為了更好的了解設計思想，執行個體盡可能簡單化。但随着需求的增加，程式将越來越複雜。此時就有修改設計的必要，重構和設計模式就可以派上用場了。最後當設計漸趨完美後，你會發現，即使需求不斷增加，你也可以神清氣閑，不用為代碼設計而煩惱了。

假定我們要設計一個媒體播放器。該媒體播放器目前隻支援音頻檔案mp3和wav。如果不談設計，設計出來的播放器可能很簡單：

public class MediaPlayer
{  
   private void PlayMp3()
   {
      MessageBox.Show("Play the mp3 file.");
   }

   private void PlayWav()
   {
      MessageBox.Show("Play the wav file.");
   }

   public void Play(string audioType)
   {      
      switch (audioType.ToLower())
      {
          case ("mp3"):
             PlayMp3();
             break;
          case ("wav"):
             PlayWav();
             break;            
      }      
   }
}

自然，你會發現這個設計非常的糟糕。因為它根本沒有為未來的需求變更提供最起碼的擴充。如果你的設計結果是這樣，那麼當你為應接不暇的需求變更而焦頭爛額的時候，你可能更希望讓這份設計到它應該去的地方，就是桌面的資源回收筒。仔細分析這段代碼，它其實是一種最古老的面向結構的設計。如果你要播放的不僅僅是 mp3和wav,你會不斷地增加相應地播放方法，然後讓switch子句越來越長，直至達到你視線看不到的地步。

好吧，我們先來體驗對象的精神。根據OOP的思想，我們應該把mp3和wav看作是一個獨立的對象。那麼是這樣嗎？

public class MP3
{
   public void Play()
   {
       MessageBox.Show("Play the mp3 file.");
   }
}

public class WAV
{
   public void Play()
   {
       MessageBox.Show("Play the wav file.");
   }
}

好樣的，你已經知道怎麼建立對象了。更可喜的是，你在不知不覺中應用了重構的方法，把原來那個垃圾設計中的方法名字改為了統一的Play()方法。你在後面的設計中，會發現這樣改名是多麼的關鍵！但似乎你并沒有擊中要害，以現在的方式去更改MediaPlayer的代碼，實質并沒有多大的變化。

既然mp3和wav都屬于音頻檔案，他們都具有音頻檔案的共性，為什麼不為它們建立一個共同的父類呢？

public class AudioMedia
{
   public void Play()
   {
       MessageBox.Show("Play the AudioMedia file.");
   }
}

現在我們引入了繼承的思想，OOP也算是象模象樣了。得意之餘，還是認真分析現實世界吧。其實在現實生活中，我們播放的隻會是某種具體類型的音頻檔案，是以這個AudioMedia類并沒有實際使用的情況。對應在設計中，就是：這個類永遠不會被執行個體化。是以，還得動一下手術，将其改為抽象類。好了，現在的代碼有點OOP的感覺了：

public abstract class AudioMedia
{
   public abstract void Play();
}

public class MP3:AudioMedia
{
   public override void Play()
   {
       MessageBox.Show("Play the mp3 file.");
   }
}

public class WAV:AudioMedia
{
   public override void Play()
   {
       MessageBox.Show("Play the wav file.");
   }
}

public class MediaPlayer
{  
   public void Play(AudioMedia media)
   {      
       media.Play();
   }
}

看看現在的設計，即滿足了類之間的層次關系，同時又保證了類的最小化原則，更利于擴充（到這裡，你會發現play方法名改得多有必要）。即使你現在又增加了對WMA檔案的播放，隻需要設計WMA類，并繼承AudioMedia，重寫Play方法就可以了，MediaPlayer類對象的Play方法根本不用改變。

是不是到此就該畫上圓滿的句号呢？然後刁鑽的客戶是永遠不會滿足的，他們在抱怨這個媒體播放器了。因為他們不想在看足球比賽的時候，隻聽到主持人的解說，他們更渴望看到足球明星在球場奔跑的英姿。也就是說，他們希望你的媒體播放器能夠支援視訊檔案。你又該痛苦了，因為在更改硬體設計的同時，原來的軟體設計結構似乎出了問題。因為視訊檔案和音頻檔案有很多不同的地方，你可不能偷懶，讓視訊檔案對象認音頻檔案作父親啊。你需要為視訊檔案設計另外的類對象了，假設我們支援RM和MPEG格式的視訊：

public abstract class VideoMedia
{
   public abstract void Play();
}

public class RM:VideoMedia
{
   public override void Play()
   {
       MessageBox.Show("Play the rm file.");
   }
}

public class MPEG:VideoMedia
{
   public override void Play()
   {
       MessageBox.Show("Play the mpeg file.");
   }
}

糟糕的是，你不能一勞永逸地享受原有的MediaPlayer類了。因為你要播放的RM檔案并不是AudioMedia的子類。

不過不用着急，因為接口這個利器你還沒有用上（雖然你也可以用抽象類，但在C#裡隻支援類的單繼承）。雖然視訊和音頻格式不同，别忘了，他們都是媒體中的一種，很多時候，他們有許多相似的功能，比如播放。根據接口的定義，你完全可以将相同功能的一系列對象實作同一個接口：

public interface IMedia
{
   void Play();
}

public abstract class AudioMedia:IMedia
{
   public abstract void Play();
}

public abstract class VideoMedia:IMedia
{
   public abstract void Play();
}

再更改一下MediaPlayer的設計就OK了：

public class MediaPlayer
{  
   public void Play(IMedia media)
   {      
       media.Play();
   }
}

現在可以總結一下，從MediaPlayer類的演變，我們可以得出這樣一個結論：在調用類對象的屬性和方法時，盡量避免将具體類對象作為傳遞參數，而應傳遞其抽象對象，更好地是傳遞接口，将實際的調用和具體對象完全剝離開，這樣可以提高代碼的靈活性。

不過，事情并沒有完。雖然一切看起來都很完美了，但我們忽略了這個事實，就是忘記了MediaPlayer的調用者。還記得文章最開始的switch語句嗎？看起來我們已經非常漂亮地除掉了這個煩惱。事實上，我在這裡玩了一個詭計，将switch語句延後了。雖然在MediaPlayer中，代碼顯得幹淨利落，其實煩惱隻不過是轉嫁到了MediaPlayer的調用者那裡。例如，在主程式界面中：

Public void BtnPlay_Click(object sender,EventArgs e)
{
    switch (cbbMediaType.SelectItem.ToString().ToLower())
    {
        IMedia media;
        case ("mp3"):
             media = new MP3();
             break;
        case ("wav"):
             media = new WAV();
             break;  
        //其它類型略；
    }
    MediaPlayer player = new MediaPlayer();
    player.Play(media);
}

使用者通過選擇cbbMediaType組合框的選項，決定播放哪一種檔案，然後單擊Play按鈕執行。

現在該設計模式粉墨登場了，這種根據不同情況建立不同類型的方式，工廠模式是最拿手的。先看看我們的工廠需要生産哪些産品呢？雖然這裡有兩種不同類型的媒體 AudioMedia和VideoMedia（以後可能更多），但它們同時又都實作IMedia接口，是以我們可以将其視為一種産品，用工廠方法模式就可以了。首先是工廠接口：

public interface IMediaFactory
{
   IMedia CreateMedia();
}

然後為每種媒體檔案對象搭建一個工廠，并統一實作工廠接口：

public class MP3MediaFactory:IMediaFactory

{

   public IMedia CreateMedia()

   {

       return new MP3();

   }

}

public class RMMediaFactory:IMediaFactory

{

   public IMedia CreateMedia()

   {

       return new RM();

   }

}

//其它工廠略；

寫到這裡，也許有人會問，為什麼不直接給AudioMedia和VideoMedia類搭建工廠呢？很簡單，因為在AudioMedia和 VideoMedia中，分别還有不同的類型派生，如果為它們搭建工廠，則在CreateMedia()方法中，仍然要使用Switch語句。而且既然這兩個類都實作了IMedia接口，可以認為是一種類型，為什麼還要那麼麻煩去請動抽象工廠模式，來生成兩類産品呢？

可能還會有人問，即使你使用這種方式，那麼在判斷具體建立哪個工廠的時候，不是也要用到switch語句嗎？我承認這種看法是對的。不過使用工廠模式，其直接好處并非是要解決 switch語句的難題，而是要延遲對象的生成，以保證的代碼的靈活性。當然，我還有最後一招殺手锏沒有使出來，到後面你會發現，switch語句其實會完全消失。

還有一個問題，就是真的有必要實作AudioMedia和VideoMedia兩個抽象類嗎？讓其子類直接實作接口不更簡單？對于本文提到的需求，我想你是對的，但不排除AudioMedia和VideoMedia它們還會存在差別。例如音頻檔案隻需要提供給聲霸卡的接口，而視訊檔案還需要提供給顯示卡的接口。如果讓MP3、WAV、RM、MPEG直接實作IMedia接口，而不通過AudioMedia和VideoMedia，在滿足其它需求的設計上也是不合理的。當然這已經不包括在本文的範疇了。

現在主程式界面發生了稍許的改變：

Public void BtnPlay_Click(object sender,EventArgs e)
{
IMediaFactory factory = null;
    switch (cbbMediaType.SelectItem.ToString().ToLower())
    {
        case ("mp3"):
             factory = new MP3MediaFactory();
             break;
        case ("wav"):
             factory = new WAVMediaFactory();
             break;  
        //其他類型略；
    }
    MediaPlayer player = new MediaPlayer();
    player.Play(factory.CreateMedia());
}

寫到這裡，我們再回過頭來看MediaPlayer類。這個類中，實作了Play方法，并根據傳遞的參數，調用相應媒體檔案的Play方法。在沒有工廠對象的時候，看起來這個類對象運作得很好。如果是作為一個類庫或元件設計者來看，他提供了這樣一個接口，供主界面程式員調用。然而在引入工廠模式後，在裡面使用MediaPlayer類已經多餘了。是以，我們要記住的是，重構并不僅僅是往原來的代碼添加新的内容。當我們發現一些不必要的設計時，還需要果斷地删掉這些備援代碼。

Public void BtnPlay_Click(object sender,EventArgs e)

{

IMediaFactory factory = null;

    switch (cbbMediaType.SelectItem.ToString().ToLower())

    {

        case (“mp3″):

             factory = new MP3MediaFactory();

             break;

        case (“wav”):

             factory = new WAVMediaFactory();

             break;

        //其他類型略；

    }

    IMedia media = factory.CreateMedia();

    media.Play();

}

如果你在最開始沒有體會到IMedia接口的好處，在這裡你應該已經明白了。我們在工廠中用到了該接口；而在主程式中，仍然要使用該接口。使用接口有什麼好處？那就是你的主程式可以在沒有具體業務類的時候，同樣可以編譯通過。是以，即使你增加了新的業務，你的主程式是不用改動的。

不過，現在看起來，這個不用改動主程式的理想，依然沒有完成。看到了嗎？在BtnPlay_Click()中，依然用new建立了一些具體類的執行個體。如果沒有完全和具體類分開，一旦更改了具體類的業務，例如增加了新的工廠類，仍然需要改變主程式，何況讨厭的switch語句仍然存在，它好像是翅膀上滋生的毒瘤，提示我們，雖然翅膀已經從僵冷的世界裡複活，但這雙翅膀還是有病的，并不能正常地飛翔。

是使用配置檔案的時候了。我們可以把每種媒體檔案類類型的相應資訊放在配置檔案中，然後根據配置檔案來選擇建立具體的對象。并且，這種建立對象的方法将使用反射來完成。首先，建立配置檔案：

然後，在主程式界面的Form_Load事件中，讀取配置檔案的所有key值，填充cbbMediaType組合框控件：

public void Form_Load(object sender, EventArgs e)
{
cbbMediaType.Items.Clear();
foreach (string key in ConfigurationSettings.AppSettings.AllKeys)
{
   cbbMediaType.Item.Add(key);
}
cbbMediaType.SelectedIndex = 0;
}

最後，更改主程式的Play按鈕單擊事件：

Public void BtnPlay_Click(object sender,EventArgs e)
{
string mediaType = cbbMediaType.SelectItem.ToString().ToLower();
string factoryDllName = ConfigurationSettings.AppSettings[mediaType].ToString();
IMediaFactory factory = (IMediaFactory)Activator.CreateInstance("MediaLibrary",factoryDllName).Unwrap ();//MediaLibray為引用的媒體檔案及工廠的程式集;
IMedia media = factory.CreateMedia();
media.Play();
}

現在鳥兒的翅膀不僅僅複活，有了可以飛的能力；同時我們還賦予這雙翅膀更強的功能，它可以飛得更高，飛得更遠！

享受自由飛翔的惬意吧。設想一下，如果我們要增加某種媒體檔案的播放功能，如AVI檔案。那麼，我們隻需要在原來的業務程式集中建立AVI類，并實作 IMedia接口，同時繼承VideoMedia類。另外在工廠業務中建立AVIMediaFactory類，并實作IMediaFactory接口。假設這個新的工廠類型為WingProject.AVIFactory，則在配置檔案中添加如下一行：

。

而主程式呢？根本不需要做任何改變，甚至不用重新編譯，這雙翅膀照樣可以自如地飛行！

轉自《異次元軟體世界》

程式設計思想┊從執行個體談面向對象程式設計(OOP)、工廠模式和重構

繼續閱讀

C/C++頭檔案、函數使用說明

寫在工作13周年

java 日期總結

程式設計高手：VC 6.0下利用消息實作内部程序通訊

VS2008 不在支援 Attributed ATL

C++之父Bjarne Stroustrup的演講：軟體理想和曆史

linux網絡程式設計----發送與接收檔案

各種二分查找

JAVA高效程式設計指南

C#多線程——前台線程和背景線程

QName是什麼

Android – ListView 中添加按鈕，動态删除添加ItemView的操作

IE8 CSS設定DIV居中，添加“margin:0 auto”

Small tricks

GridView終極用法(一)

工廠模式-三種類型