這篇博文是從實際生活中，提煉出來的設計理念，它現在是骨架，現在我加以代碼實例，完成程序的血肉，以求讓大家活生生的體會設計中的精髓。
自從我們學習面向對象編程以來，它方便了我們的思維思考模式，一個事物具備什么，就以對應的屬性及方法加之。
(￣▽￣) 沒有什么難的，但是你學到的是最基礎的語法和連自己都不是很了解的語言，用一段C語言程序，你可以很輕松的把它改成C#，JAVA等，這有什么難的？大多數程序員們扭曲了C#語言，把C的語法都移植到C#上（在我不了解C#的時候，我自己都這么做過），錯了不可怕，可怕的是錯了還不肯改。
語言是一種工具，學會了都是想通的，但是設計思想不同決定了語言的本質區別。
進入正題，一步一步來剖析一個簡單的鴨子游戲程序。
首先設計一個鴨子對象，是不是？大致這樣：
1 public class Duck 2 { 3 void quack(){ 4 //...鴨子都會叫 5 } 6 void swim(){ 7 //...都會游泳 8 } 9 void Display() { 10 //...外觀 11 } 12 }
然后鴨子游戲中有各種鴨子一邊游泳戲水，一邊呷呷叫，各種鴨子都繼承Duck類哦，游戲在預料之中運行。
這應該是標准的OO（Object Oriented）技術吧？游戲完美運行中.........
目前鴨子會叫會游泳，都在水里多沒意思？來個創新吧：
丑小鴨也能飛上青天？？o(∩_∩)o
現在想要鴨子飛，那么就要給鴨子添加一個飛行方法，好比這樣：
public class Duck { void quack(){ //...鴨子都會叫 } void swim(){ //...都會游泳 } void Display() { //...外觀 } void Fly() { //...飛行 } }
方法已加，游戲中的小鴨子們可以飛咯。
現在問題，才剛剛出現：
在演示程序的時候，“橡皮假鴨”在屏幕上飛來飛去，游戲里面有各種各樣的鴨子。
當沒有Fly()的時候，小鴨子們可以很平穩的運行。在父類中加上Fyl(),會導致所有的子類都具備Fly(),連那些不該具備的子類也無法免除，所以：
對代碼所做的局部修改，影響層面可不只是局部。
看看這張圖，說不定和你的想法不謀而合：
覆蓋掉“橡皮鴨”的飛行方式。這是個不錯的選擇，這樣一來，“橡皮鴨”也不會到處亂飛了~~（注意哦“橡皮鴨”會叫的--“吱吱”）。
游戲中現在又加入一種鴨子~問題又來啦~~
現在加入成員是-“誘餌鴨”（DecoyDuck）它是木頭做的假鴨，它不會飛當然也不會叫~
OK，現在對於這個新成員，就這么做：
繼續覆蓋它的方法，它只有老老實實的在水里面游！
你們覺得這種繁瑣的工作，什么時候才是個頭呢？鴨子種類無限，你的噩夢無限~繼承這個解決方法，看來果斷不行啊，要換要換。
你覺得這個設計怎么樣：
我定義一些接口，目前先做兩個，一個Flyable,一個Quackable：
Duck類也改掉，只包含兩個方法：Swim（），Display（）:
然后讓不同的子類再繼承Duck類的時候，分別實現一下Fly()和Quack()，接口也用上了，你覺得怎么樣？
好像有點用，但是，再換個大的角度想，子類繼承實現的那些Fly()，Quack()都是些重復代碼，然而，重復代碼是可以接受的，但是，在你維護的時候，假如有30個Duck子類吧，要稍稍修改一下那個Fly()，有沒有覺得可維護性瞬間就低到下限？
在這個新的設計方法中，雖然解決了“一部分”問題，但是，這造成了代碼無法復用！有沒有覺得？還有更可怕的哦，會飛的鴨子，那飛行動作可不是千篇一律的，來個空翻360°旋轉這個動作，你又要怎么做？o(∩_∩)o
不管你在何處工作，用何種編程語言，在軟件開發上，一直伴隨你的那個不變真理是什么？ （把你想到的答案，寫在評論上吧^_^，期待你的回答）
把這個先前的設計都清零……
現在我們知道使用繼承並不能很好的解決問題，因為鴨子的行為在子類里不斷地改變，並且讓那些子類都有這些行為是不恰當的，Flyable和Quackable接口似乎不錯，解決了問題（只有會飛的鴨子才繼承Flyable），但是這依舊讓你有很多任務去做，你依舊不能做到代碼復用，你在維護的時候，依舊要往下追蹤，一 一去修改對應的行為。
對於這個問題，現在真正有個設計原則，能解決這個問題，它能實現代碼復用，能添加和修改使系統變得更有彈性。
設計原則：
找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。
這是些理論知識，對於骨架，我會豐滿出它的羽翼。繼續看吧，你會有收獲！
現在，是時候取出Duck類中的變化的部分了！
目前可變的是fly和quack相關部分，它們會變化，現在單獨把這兩個行為從Duck類中分開，建立一種組新類代表每個行為。
先做個飛行行為的接口：
1 public interface FlyBehavior 2 { 3 void Fly(); 4 }
呷呷叫行為的接口：
1 public interface QuackBehavior 2 { 3 void quack(); 4 }
是否聽說過這么一個設計理念：
針對接口編程，而不是針對實現編程。
而“針對接口編程”真正的意思是“針對抽象類編程”。
“針對接口編程”的關鍵就在多態。利用多態，程序可以在針對抽象類編程，執行時會根據實際狀況執行到真正的行為，不會被綁死在抽象類的行為上。
再深挖一點，“針對抽象類編程”這句話，可以更明確地說成“變量的聲明類型，應該是抽象類型，這可以是一個抽象類，或是一個接口”！不理解沒關系！接下來我們用程序來讓大家慢慢吃透這個概念！
舉個傳統的例子：
針對實現編程：
1 Dog d = new Dog(); 2 d.bark();//“汪汪”叫行為
針對接口或抽象類編程：
Animal animal = new Dog(); animal.makeSound();//這個方法實現“汪汪”叫
這個不明白？沒關系，有圖：
現在讓我們來重新實現鴨子游戲中的設計吧！
先設計飛行行為：
class FlyWithWings:FlyBehavior { public void Fly() { Console.WriteLine("我會飛啦~！"); } } class FlyNoWay : FlyBehavior { public void Fly() { //什么都不做，它不會飛 } }
我把兩個類放在一起了，這方便大家閱讀，實際上應該分開的。
再看看“呷呷”叫行為：
1 class Quack : QuackBehavior 2 { 3 public void quack() 4 { 5 Console.WriteLine("呷呷!"); 6 } 7 } 8 9 class Squeak : QuackBehavior 10 { 11 public void quack() { 12 Console.WriteLine("吱吱！");//橡皮鴨 13 } 14 } 15 16 class MuteQuack:QuackBehavior 17 { 18 public void quack() 19 { 20 Console.WriteLine(".......");//"誘餌鴨"不會叫 21 } 22 }
行為做好了~來實現Duck類
1 public abstract class Duck 2 { 3 public FlyBehavior flybehavior; 4 public QuackBehavior quackbehavior; 5 6 public void performQuack() { 7 quackbehavior.quack(); 8 } 9 public void performFly() 10 { 11 flybehavior.Fly(); 12 } 13 public virtual void Swim(){ 14 Console.WriteLine("~~游~~"); 15 } 16 public virtual void Display(){} 17 }
結構很簡單，不是嗎？定義QuackBehavior，FlyBehavior，每只鴨子都會引用實現QuackBehavior接口對象，讓它們來處理鴨子的行為。
想要呷呷叫的效果，就要quackbehavior對象去呷呷叫就可以了，我們現在不用再關心quackbehavior接口的對象是什么，只要關系Duck如何叫就行了。
這個quackbehavior接口可以重用了哦。有沒有發現？在什么地方可以重用呢？思考下，我后面再提。
好了，現在來具體實現鴨子實體了：
1 public class MallarDuck : Duck 2 { 3 public MallarDuck() { 4 quackbehavior = new Quack(); 5 flybehavior = new FlyWithWings(); 6 } 7 public override void Display() 8 { 9 Console.WriteLine("我是一只美麗的綠頭鴨！"); 10 } 11 }
o(∩_∩)o大功就要告成了， 看Program：
1 static void Main(string[] args) 2 { 3 MallarDuck mallard = new MallarDuck(); 4 mallard.Display(); 5 mallard.Swim(); 6 mallard.performQuack(); 7 mallard.performFly(); 8 9 }
一目了然，這個程序要做什么，怎么做，很簡單吧？
看看運行結果：
代碼也貼完了，程序確實可以運行，現在看下這個設計的最后一個概念：
多用組合，少用繼承。
正如你看見的，使用組合建立系統具有很大的彈性，不僅僅將算法族封裝成類，更可以在“運行時動態地改變行為”。
不知道什么是“運行時動態地改變行為”？？
好，那我再演示一個，就拿那美麗的綠頭鴨做例子：
Duck類最新修改：
1 public abstract class Duck 2 { 3 public FlyBehavior flybehavior; 4 public QuackBehavior quackbehavior; 5 6 public void performQuack() { 7 quackbehavior.quack(); 8 } 9 public void performFly() 10 { 11 flybehavior.Fly(); 12 } 13 public virtual void Swim(){ 14 Console.WriteLine("~~游~~"); 15 } 16 public virtual void Display(){} 17 18 public void SetFlyBehavior(FlyBehavior flyb)//額外添加 19 { 20 flybehavior = flyb; 21 } 22 23 }
然后我再添加一個火箭動力：
class FlyRockePowered : FlyBehavior { public void Fly() { Console.WriteLine("打了雞血！4200米/秒，加速飛行！"); } }
看看Program：
1 class Program 2 { 3 static void Main(string[] args) 4 { 5 MallarDuck mallard = new MallarDuck(); 6 mallard.Display(); 7 mallard.Swim(); 8 mallard.performQuack(); 9 mallard.performFly(); 10 11 mallard.SetFlyBehavior(new FlyRockePowered()); 12 mallard.performFly(); 13 } 14 }
結果：
動態添加了吧？修改一下很容易吧？
至於那個quackbehavior接口重用問題：
鴨鳴器知道吧？獵人用這個東西模擬鴨子叫，引誘野鴨，這個不是個很好的重用嗎？o(∩_∩)o 更多重用只局限於你的想象~
如果你認真看完了這個，那么下面這個獎章是給予你的：
你學會了策略者設計模式
o(∩_∩)o
你再也不用擔心系統遇到任何變化。
策略者模式
定義了算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化獨立於使用算法的用戶。