以下轉自http://www.cnblogs.com/zhenyulu/articles/41388.html
十年前，我有一個很有錢的朋友，他家有三輛汽車（VOLVO（沃爾沃）、BENCH（奔馳）、MAZDA（馬自達）），還雇了司機為他開車。不過， 這個人上車后跟司機說的話取決于他坐的車：當他坐上VOLVO后，會跟司機說“開沃爾沃車！”，坐上BENCH后他說“開奔馳車！”，坐上MAZDA后他 說“開馬自達車！”。
大家猜這個人怎么著？.....有病！
其實我這個朋友叫“C”。
注：我對C一直很虔誠，上大學時，C語言是我最喜愛的語言。而且它的功能要遠比我在后面例子中描述的功能強大的多（畢竟還有殺手锏“指針”呢），我并不想讓這段故事給C留下什么不好的印象，只是舉例而已（BASIC和VFP什么的連舉例資格都沒有呢 ）。
把上面的故事用C寫下來的化就是（我在Tubro C++ 1.0下調試通過）：
程序編譯成可執行文件后，在命令提示符下輸入: CARTEST V 或 CARTEST B 或 CARTEST M。程序自動完成開不同車的功能。
現在讓我們看看C先生病在哪里？其實，C先生之所以“有病”，就是在他發號的施令上，實際上只要說聲“開車”就行了，他卻不厭其煩的在里面加上車名（DriveVolvo(); DriveBench(); DriveMazda();）。
如果用用C#改寫上面的程序的話，我們可以將程序寫成：
現在問題就出來了，這兩種做法哪種更好一些呢？是不是C#將本是很簡單的問題搞復雜了呢？讓我們分析一下：
C#程序通過對車的抽象，實現只需“開車”，就可以調用任何車的開車方法。這就是我們常說的“多態性”。將多態性濃縮到兩行代碼上，就是（以下簡稱方法一）：
不要小看這兩行代碼，隱藏在其中的深意還需要我們好好挖掘一下。
有人可能會問，不就是開車嗎，開奔馳就是開奔馳，干嗎要把奔馳賦值給車，然后調用車的開車，再通過多態性轉而調用奔馳的開車。如此麻煩，不如直接就調用奔馳的開車（以下簡稱方法二）：
到底誰好誰壞，我們可以從兩個角度來看這個問題：
一、從迪米特法則的角度來看：
（關于迪米特法則，請參考：C#設計模式（3））
迪米特法則可以簡單的表述成最小知識原則，也叫做“使民無知”。一個對象應當對其它對象知道的越少越好。
如果客戶在進行代碼調用時，使用了方法二的方法，那么當不開奔馳轉開沃爾沃時，必須將客戶端所有Bench的代碼改為Volvo。如果兩個車都可能開的化，那么客戶端不得不跟兩個對象都打交道。
如果采用方法一的方法，客戶只需要知道“車”就行了，反正車都可以開。至于什么車，客戶并不關心，關鍵的是能開就行。這不但很好的應用了迪米特法則，同時也應用了里氏代換原則（參見：C#設計模式（2））：“一個子類可以替換掉父類”。這允許在客戶不知情的情況下就可以代換不同類型的車。
二、從開放封閉原則的角度來看：
（關于開放封閉原則，請參考：C#設計模式（2））
開 放封閉原則要求對修改封閉，對擴展開放。在上面的兩個例子種，方法二沒有很好遵循開放封閉原則，當添加新類型汽車后，不得不修改代碼以適應這種改變。而方 法一具有很強的適應性，只需要給Car對象添加一個子類就可以了，客戶由于只知道有“車”，所以加一種新車后，根本不需要改變客戶端代碼。因此也提高了系 統的可維護性。
Copyright @ baby-fly Powered by: .Text and ASP.NET Theme by: .NET Monster