這篇博文是從實際生活中，提煉出來的設計理念，它現在是骨架，現在我加以代碼實例，完成程序的血肉，以求讓大家活生生的體會設計中的精髓。
自從我們學習面向對象編程以來，它方便了我們的思維思考模式，一個事物具備什么，就以對應的屬性及方法加之。
(▽) 沒有什么難的，但是你學到的是最基礎的語法和連自己都不是很了解的語言，用一段C語言程序，你可以很輕松的把它改成C#，JAVA等，這有什么難的？大多數程序員們扭曲了C#語言，把C的語法都移植到C#上（在我不了解C#的時候，我自己都這么做過），錯了不可怕，可怕的是錯了還不肯改。
語言是一種工具，學會了都是想通的，但是設計思想不同決定了語言的本質區別。
進入正題，一步一步來剖析一個簡單的鴨子游戲程序。
首先設計一個鴨子對象，是不是？大致這樣：
復制代碼 代碼如下:
public class Duck
{
void quack(){
//...鴨子都會叫
}
void swim(){
//...都會游泳
}
void Display() {
//...外觀
}
}
然后鴨子游戲中有各種鴨子一邊游泳戲水，一邊呷呷叫，各種鴨子都繼承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類中分開，建立一種組新類代表每個行為。
先做個飛行行為的接口：
public interface FlyBehavior
{
void Fly();
}
呷呷叫行為的接口：
public interface QuackBehavior
{
void quack();
}
是否聽說過這么一個設計理念：
針對接口編程，而不是針對實現編程。
而“針對接口編程”真正的意思是“針對抽象類編程”。
“針對接口編程”的關鍵就在多態。利用多態，程序可以在針對抽象類編程，執行時會根據實際狀況執行到真正的行為，不會被綁死在抽象類的行為上。
再深挖一點，“針對抽象類編程”這句話，可以更明確地說成“變量的聲明類型，應該是抽象類型，這可以是一個抽象類，或是一個接口”！不理解沒關系！接下來我們用程序來讓大家慢慢吃透這個概念！
舉個傳統的例子：
針對實現編程：
Dog d = new Dog();
d.bark();//“汪汪”叫行為
針對接口或抽象類編程：
Animal animal = new Dog();
animal.makeSound();//這個方法實現“汪汪”叫
這個不明白？沒關系，有圖：
現在讓我們來重新實現鴨子游戲中的設計吧！
先設計飛行行為：
復制代碼 代碼如下:
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 更多重用只局限于你的想象~
如果你認真看完了這個，那么下面這個獎章是給予你的：
你學會了策略者設計模式
o(∩_∩)o
你再也不用擔心系統遇到任何變化
策略者模式
定義了算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化獨立于使用算法的用戶。
看完啦，如果覺得還不錯，就點下推薦吧。o(∩_∩)o 這是對我的支持，謝謝
