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