為生存而奔跑

工廠方法模式定義了一個創建對象的接口,但由子類決定要實例化的類是哪個.工廠方法讓類把實例化推遲到子類

以下轉自http://www.cnblogs.com/zhenyulu/articles/41388.html

十年前，我有一個很有錢的朋友，他家有三輛汽車（VOLVO（沃爾沃）、BENCH（奔馳）、MAZDA（馬自達）），還雇了司機為他開車。不過， 這個人上車后跟司機說的話取決于他坐的車：當他坐上VOLVO后，會跟司機說“開沃爾沃車！”，坐上BENCH后他說“開奔馳車！”，坐上MAZDA后他 說“開馬自達車！”。

大家猜這個人怎么著？.....有?。?/p>

其實我這個朋友叫“C”。

注：我對C一直很虔誠，上大學時，C語言是我最喜愛的語言。而且它的功能要遠比我在后面例子中描述的功能強大的多（畢竟還有殺手锏“指針”呢），我并不想讓這段故事給C留下什么不好的印象，只是舉例而已（BASIC和VFP什么的連舉例資格都沒有呢  ）。

把上面的故事用C寫下來的化就是（我在Tubro C++ 1.0下調試通過）：

程序編譯成可執行文件后，在命令提示符下輸入: CARTEST V 或 CARTEST B 或 CARTEST M。程序自動完成開不同車的功能。

現在讓我們看看C先生病在哪里？其實，C先生之所以“有病”，就是在他發號的施令上，實際上只要說聲“開車”就行了，他卻不厭其煩的在里面加上車名（DriveVolvo(); DriveBench(); DriveMazda();）。

如果用用C#改寫上面的程序的話，我們可以將程序寫成：

現在問題就出來了，這兩種做法哪種更好一些呢？是不是C#將本是很簡單的問題搞復雜了呢？讓我們分析一下：

1. 從代碼長度來看，顯然C語言的代碼長度要遠少于C#的代碼。兩程序完成的是相同的功能。
2. 從代碼結構上看，C語言的結構也要比C#清晰，屬于典型的結構化程序設計。
3. 從“有病”的角度看，顯然C語言程序“有病”，而C#程序更為容易接受。

C#程序通過對車的抽象，實現只需“開車”，就可以調用任何車的開車方法。這就是我們常說的“多態性”。將多態性濃縮到兩行代碼上，就是（以下簡稱方法一）：

不要小看這兩行代碼，隱藏在其中的深意還需要我們好好挖掘一下。

有人可能會問，不就是開車嗎，開奔馳就是開奔馳，干嗎要把奔馳賦值給車，然后調用車的開車，再通過多態性轉而調用奔馳的開車。如此麻煩，不如直接就調用奔馳的開車（以下簡稱方法二）：

到底誰好誰壞，我們可以從兩個角度來看這個問題：

一、從迪米特法則的角度來看：

（關于迪米特法則，請參考：C#設計模式（3））

迪米特法則可以簡單的表述成最小知識原則，也叫做“使民無知”。一個對象應當對其它對象知道的越少越好。

如果客戶在進行代碼調用時，使用了方法二的方法，那么當不開奔馳轉開沃爾沃時，必須將客戶端所有Bench的代碼改為Volvo。如果兩個車都可能開的化，那么客戶端不得不跟兩個對象都打交道。

如果采用方法一的方法，客戶只需要知道“車”就行了，反正車都可以開。至于什么車，客戶并不關心，關鍵的是能開就行。這不但很好的應用了迪米特法則，同時也應用了里氏代換原則（參見：C#設計模式（2））：“一個子類可以替換掉父類”。這允許在客戶不知情的情況下就可以代換不同類型的車。

二、從開放封閉原則的角度來看：

（關于開放封閉原則，請參考：C#設計模式（2））

開 放封閉原則要求對修改封閉，對擴展開放。在上面的兩個例子種，方法二沒有很好遵循開放封閉原則，當添加新類型汽車后，不得不修改代碼以適應這種改變。而方 法一具有很強的適應性，只需要給Car對象添加一個子類就可以了，客戶由于只知道有“車”，所以加一種新車后，根本不需要改變客戶端代碼。因此也提高了系 統的可維護性。

工廠模式中之所以引入“工廠”的概念，而拋棄直接使用 new 實例化對象，其中一個根本的原因也在于此。通過對“簡單工廠模式”、“工廠方法模式”以及“抽象工廠模式”的學習我們會很強的感受到這點。