【設計模式】策略模式與狀態模式。

　　策略模式與狀態模式在實現上有共同之處，都是把不同的情形抽象為統一的接口來實現，就放在一起進行記錄。2個模式的UML建模圖基本相似，區別在於狀態模式需要在子類實現與context相關的一個狀態行為。

　　狀態模式的的思想是，狀態之間的切換，在狀態A執行完畢后自己控制狀態指向狀態B。狀態模式是不停的切換狀態執行。

　　策略模式的思想上是，考慮多種不同的業務規則將不同的算法封裝起來，便於調用者選擇調用。策略模式只是條件選擇執行一次。

 　　策略模式

1. Strategy: 定義所有支持的算法的公共接口抽象類.
2. ConcreteStrategy: 封裝了具體的算法或行為，繼承於Strategy
3. Context: 用一個ConcreteStrategy來配置，維護一個對Strategy對象的引用。

　　

 　　狀態模式

1. State: 抽象狀態類，定義一個接口以封裝與context的一個狀態相關的行為
2. ConcreteState: 具體狀態，每一子類實現一個與Context的一個狀態相關的行為
3. Context: 維護一個ConcreteState子類的實例，這個實例定義當前的狀態。

使用場景：

　　狀態模式主要解決的是當控制一個對象狀態轉換的條件表達式過於復雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把復雜的判斷邏輯簡化。當一個對象的行為取決於它的狀態，並且它必須在運行時刻根據狀態改變它的行為時，就可以考慮使用狀態模式了。

　　策略模式的Strategy類層次為Context定義了一系列的可供重用的算法或行為。繼承有助於析取出這些算法中的公共功能。在實踐中，我們發現可以用它來封裝幾乎任何類型的規則，只要在分析過程中聽到需要在不同時間應用不同的業務規則，就可以考慮使用策略模式處理這種變化的可能性。

 

 

　狀態模式和策略模式的比較

　　兩個模式的實現類圖雖然一致，但是實現目的不一樣！

　　首先知道，策略模式是一個接口的應用案例，一個很重要的設計模式，簡單易用，策略模式一般用於單個算法的替換，客戶端事先必須知道所有的可替換策略，由客戶端去指定環境類需要哪個策略，注意通常都只有一個最恰當的策略（算法）被選擇。其他策略是同級的，可互相動態的在運行中替換原有策略。

　　而狀態模式的每個狀態子類中需要包含環境類（Context）中的所有方法的具體實現——條件語句。通過把行為和行為對應的邏輯包裝到狀態類里，在環境類里消除大量的邏輯判斷，而不同狀態的切換由繼承（實現）State的狀態子類去實現，當發現修改的當前對象的狀態不是自己這個狀態所對應的參數，則各個狀態子類自己給Context類切換狀態（有職責鏈模式思想）！且客戶端不直接和狀態類交互，客戶端不需要了解狀態！（和策略不一樣），策略模式是直接依賴注入到Context類的參數進行選擇策略，不存在切換狀態的操作，客戶端需要了解策略！

　　聯系：狀態模式和策略模式都是為具有多種可能情形設計的模式，把不同的處理情形抽象為一個相同的接口（抽象類），符合對開閉原則，且策略模式更具有一般性，在實踐中，可以用策略模式來封裝幾乎任何類型的規則，只要在分析過程中聽到需要在不同實踐應用不同的業務規則，就可以考慮使用策略模式處理，在這點上策略模式是包含狀態模式的功能的。

小結：狀態模式的使用場景是什么？

　　狀態模式主要解決的是（目的or意圖）：控制一個對象內部的狀態轉換的條件表達式過於復雜時的情況，且客戶端調用之前不需要了解具體狀態。它把狀態的判斷邏輯轉到表現不同狀態的一系列類當中，可以把復雜的判斷邏輯簡化。維持開閉原則，方便維護

，還有重要一點下面會總結，狀態模式是讓各個狀態對象自己知道其下一個處理的對象是誰！即在狀態子類編譯時在代碼上就設定好了！

 

　　狀態模式的優缺點都是什么？　　

　　優點，前面說了很多了……

• 狀態模式使得代碼中復雜而庸長的邏輯判斷語句問題得到了解決，而且狀態角色將具體的狀態和他對應的行為及其邏輯判斷封裝了起來，這使得增加一種新的狀態顯得十分簡單。
• 把容易出錯的if-else語句在環境類 or 客戶端中消除，方便維護。
• 每一個狀態類都符合“開閉”原則——對狀態的修改關閉，對客戶端的擴展開放，可以隨時增加新的Person的狀態，或者刪除。
• State類在只有行為需要抽象時，就用接口，有其他共同功能可以用抽象類，這點和其他一些（策略）模式類似。

      缺點：

　　使用狀態模式時，每個狀態對應一個具體的狀態類，使結構分散，類的數量變得很多！使得程序結構變得稍顯復雜，閱讀代碼時相對之前比較困難，不過對於優秀的研發人員來說，應該是微不足道的。因為想要獲取彈性！就必須付出代價！除非我們的程序是一次性的！用完就丟掉……如果不是，那么假設有一個系統，某個功能需要很多狀態，如果不使用狀態模式優化，那么在環境類（客戶端類）里會有大量的整塊整塊的條件判斷語句！

 

　　

Strategy模式有下面的一些優點：
1) 相關算法系列 Strategy類層次為Context定義了一系列的可供重用的算法或行為。 繼承有助於析取出這些算法中的公共功能。
2) 提供了可以替換繼承關系的辦法： 繼承提供了另一種支持多種算法或行為的方法。你可以直接生成一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編制到 Context中，而將算法的實現與Context的實現混合起來,從而使Context難以理解、難以維護和難以擴展，而且還不能動態地改變算法。最后你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的算法或行為。 將算法封裝在獨立的Strategy類中使得你可以獨立於其Context改變它，使它易於切換、易於理解、易於擴展。
3) 消除了一些if else條件語句 ：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件語句來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件語句。含有許多條件語句的代碼通常意味着需要使用Strategy模式。
4) 實現的選擇 Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取舍要求從不同策略中進行選擇。

Strategy模式缺點:

1)客戶端必須知道所有的策略類，並自行決定使用哪一個策略類:  本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通信開銷 ：無論各個ConcreteStrategy實現的算法是簡單還是復雜, 它們都共享Strategy定義的接口。因此很可能某些 ConcreteStrategy不會都用到所有通過這個接口傳遞給它們的信息；簡單的 ConcreteStrategy可能不使用其中的任何信息！這就意味着有時Context會創建和初始化一些永遠不會用到的參數。如果存在這樣問題 , 那么將需要在Strategy和Context之間更進行緊密的耦合。
3 )策略模式將造成產生很多策略類：可以通過使用享元模式在一定程度上減少對象的數量。 增加了對象的數目 Strategy增加了一個應用中的對象的數目。有時你可以將 Strategy實現為可供各Context共享的無狀態的對象來減少這一開銷。任何其余的狀態都由 Context維護。Context在每一次對Strategy對象的請求中都將這個狀態傳遞過去。共享的 Strategy不應在各次調用之間維護狀態。

 

 

 public interface IStrategy
    {
       double CountMoney(double money);
    }


   public class discountA:IStrategy
    {
        public double CountMoney(double money)
        {
            return money * 0.8;
           // throw new NotImplementedException();
        }
    }

  /// <summary>
    /// 打折活動B
    /// </summary>
   public class discountB:IStrategy
    {

       /// <summary>
       /// 滿100-20
       /// </summary>
       /// <param name="money"></param>
       /// <returns></returns>
        public double CountMoney(double money)
        {
            return money - ((int)(money / 100) * 20);
            //throw new NotImplementedException();
        }
    }

public class Strategy
    {
       IStrategy iStrategy;
       public Strategy(IStrategy strategy)
       {
           iStrategy = strategy;
       }
       public double CountMoney(double money)
       {
           return iStrategy.CountMoney(money);
       }
    }

 public class MainStrategys
    {
       public MainStrategys()
       {
           Strategy strategt;
           //執行A打折策略
           discountA da = new discountA();
           strategt = new Strategy(da);
           Console.WriteLine("A打折策略--"+strategt.CountMoney(111));

           //執行B打折策略
           discountB db = new discountB();
           strategt = new Strategy(db);
           Console.WriteLine("B打折策略--" + strategt.CountMoney(111));

           Console.ReadKey();
       }
    }

  public  interface IState
    {
       void Submit(FileSub file);
    }

 public class BeginState :IState
    {

        public void Submit(FileSub file)
        {
            Console.WriteLine("begin-------");
            file.SetState(new WorkingState());
        }
    }

 public  class WorkingState:IState
    {
        public void Submit(FileSub file)
        {
            Console.WriteLine("working-------------");
            file.SetState(new EndState());
            //throw new NotImplementedException();
        }
    }


 public class EndState:IState
    {
        public void Submit(FileSub file)
        {
            Console.WriteLine("end------------");
            file.SetState(new BeginState());
            //throw new NotImplementedException();
        }
    }

 public class FileSub
    {
        private IState istate;
        public FileSub()
        {
            istate = new BeginState();
        }
        public void SetState(IState state)
        {
            istate = state;
        }
        public void Submit()
        {
            istate.Submit(this);
        }
    }

    public class Main
    {
        public Main()
        {
            FileSub file = new FileSub();
            file.SetState(new BeginState());
            file.Submit();
            file.Submit();
            file.Submit();
            Console.ReadKey();
        }
    }