工廠方法模式定義了一個(gè)創(chuàng)建對(duì)象的接口,但由子類決定要實(shí)例化的類是哪個(gè).工廠方法讓類把實(shí)例化推遲到子類

以下轉(zhuǎn)自http://www.cnblogs.com/zhenyulu/articles/41388.html

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

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

其實(shí)我這個(gè)朋友叫“C”。

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

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

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

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

如果用用C#改寫上面的程序的話，我們可以將程序?qū)懗桑?/p>

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

1. 從代碼長(zhǎng)度來看，顯然C語(yǔ)言的代碼長(zhǎng)度要遠(yuǎn)少于C#的代碼。兩程序完成的是相同的功能。
2. 從代碼結(jié)構(gòu)上看，C語(yǔ)言的結(jié)構(gòu)也要比C#清晰，屬于典型的結(jié)構(gòu)化程序設(shè)計(jì)。
3. 從“有病”的角度看，顯然C語(yǔ)言程序“有病”，而C#程序更為容易接受。

C#程序通過對(duì)車的抽象，實(shí)現(xiàn)只需“開車”，就可以調(diào)用任何車的開車方法。這就是我們常說的“多態(tài)性”。將多態(tài)性濃縮到兩行代碼上，就是（以下簡(jiǎn)稱方法一）：

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

有人可能會(huì)問，不就是開車嗎，開奔馳就是開奔馳，干嗎要把奔馳賦值給車，然后調(diào)用車的開車，再通過多態(tài)性轉(zhuǎn)而調(diào)用奔馳的開車。如此麻煩，不如直接就調(diào)用奔馳的開車（以下簡(jiǎn)稱方法二）：

到底誰(shuí)好誰(shuí)壞，我們可以從兩個(gè)角度來看這個(gè)問題：

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

（關(guān)于迪米特法則，請(qǐng)參考：C#設(shè)計(jì)模式（3））

迪米特法則可以簡(jiǎn)單的表述成最小知識(shí)原則，也叫做“使民無知”。一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其它對(duì)象知道的越少越好。

如果客戶在進(jìn)行代碼調(diào)用時(shí)，使用了方法二的方法，那么當(dāng)不開奔馳轉(zhuǎn)開沃爾沃時(shí)，必須將客戶端所有Bench的代碼改為Volvo。如果兩個(gè)車都可能開的化，那么客戶端不得不跟兩個(gè)對(duì)象都打交道。

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

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

（關(guān)于開放封閉原則，請(qǐng)參考：C#設(shè)計(jì)模式（2））

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

工廠模式中之所以引入“工廠”的概念，而拋棄直接使用 new 實(shí)例化對(duì)象，其中一個(gè)根本的原因也在于此。通過對(duì)“簡(jiǎn)單工廠模式”、“工廠方法模式”以及“抽象工廠模式”的學(xué)習(xí)我們會(huì)很強(qiáng)的感受到這點(diǎn)。