無廢話C#設計模式之十六：State

意圖

    允許一個對象在其內部狀態改變時改變它的行爲。對象看起來似乎修改了它的類。

場景

    我們在製作一個網上書店的網站，用戶在書店買了一定金額的書後可以升級爲銀會員、黃金會員，不同等級的會員購買書籍有不同的優惠。你可能會想到可以在User類的BuyBook方法中判斷用戶歷史消費的金額來給用戶不同的折扣，在GetUserLevel方法中根據用戶歷史消費的金額來輸出用戶的等級。帶來的問題有三點：

不用等級的用戶給予的優惠比率是經常發生變化的，一旦變化是不是就要修改User類呢？

網站在初期可能最高級別的用戶是黃金會員，而隨着用戶消費金額的累計，我們可能要增加鑽石、白金等會員類型，這些會員的折扣又是不同的，發生這樣的變化是不是又要修改User類了呢？

拋開變化不說，User類承擔了用戶等級判斷、購買折扣計算等複雜邏輯，複雜的User類代碼的可維護性會不會很好呢？
由此引入State模式，通過將對象和對象的狀態進行分離，把對象狀態的轉化以及由不同狀態產生的行爲交給具體的狀態類去做，解決上述問題。

1. using System;
3. using System.Collections.Generic;
5. using System.Text;
7.  
9. namespace StateExample
11. {
13.     class Program
15.     {
17.         static void Main(string[] args)
19.         {
21.             User user = new User("zhuye");
23.             user.BuyBook(2000);
25.             user.BuyBook(2000);
27.             user.BuyBook(2000);
29.             user.BuyBook(2000);
31.         }
33.     }
35.  
37.     class User
39.     {
41.         private UserLevel userLevel;
43.  
45.         public UserLevel UserLevel
47.         {
49.             get { return userLevel; }
51.             set { userLevel = value; }
53.         }
55.  
57.         private string userName;
59.  
61.         private double paidMoney;
63.  
65.         public double PaidMoney
67.         {
69.             get { return paidMoney; }
71.         }
73.  
75.         public User(string userName)
77.         {
79.             this.userName = userName;
81.             this.paidMoney = 0;
83.             this.UserLevel = new NormalUser(this);
85.         }
87.  
89.         public void BuyBook(double amount)
91.         {
93.             Console.WriteLine(string.Format("Hello {0}, You have paid ${1}, You Level is {2}.", userName, paidMoney, userLevel.GetType().Name));
95.             double realamount = userLevel.CalcRealAmount(amount);
97.             Console.WriteLine("You only paid $" + realamount + " for this book.");
99.             paidMoney += realamount;
101.             userLevel.StateCheck();            
103.         }
105.     }
107.  
109.     abstract class UserLevel
111.     {
113.         protected User user;
115.  
117.         public UserLevel(User user)
119.         {
121.             this.user = user;
123.         }
125.  
127.         public abstract void StateCheck();
129.         public abstract double CalcRealAmount(double amount);
131.     }
133.  
135.     class DiamondUser : UserLevel
137.     {
139.         public DiamondUser(User user)
141.             : base(user) { }
143.  
145.         public override double CalcRealAmount(double amount)
147.         {
149.             return amount * 0.7;
151.         }
153.  
155.         public override void StateCheck()
157.         {
159.  
161.         }
163.  
165.     }
167.  
169.     class GoldUser : UserLevel
171.     {
173.         public GoldUser(User user)
175.             : base(user) { }
177.  
179.         public override double CalcRealAmount(double amount)
181.         {
183.             return amount * 0.8;
185.         }
187.  
189.         public override void StateCheck()
191.         {
193.             if (user.PaidMoney > 5000)
195.                 user.UserLevel = new DiamondUser(user);
197.         }
199.     }
201.  
203.     class SilverUser : UserLevel
205.     {
207.         public SilverUser(User user)
209.             : base(user) { }
211.  
213.         public override double CalcRealAmount(double amount)
215.         {
217.             return amount * 0.9;
219.         }
221.  
223.         public override void StateCheck()
225.         {
227.             if (user.PaidMoney > 2000)
229.                 user.UserLevel = new GoldUser(user);
231.         }
233.     }
235.  
237.     class NormalUser : UserLevel
239.     {
241.         public NormalUser(User user)
243.             : base(user) { }
245.  
247.         public override double CalcRealAmount(double amount)
249.         {
251.             return amount * 0.95;
253.         }
255.  
257.         public override void StateCheck()
259.         {
261.             if (user.PaidMoney > 1000)
263.                 user.UserLevel = new SilverUser(user);
265.         }
267.     }
269. }

代碼說明
    User類型是環境角色。它的作用一是定義了客戶端感興趣的方法（購買書籍），二是擁有一個狀態實例，它定義了用戶的當前狀態（普通會員、銀會員、黃金會員還是鑽石會員）。

    UserLevel類型是抽象狀態角色。它的作用一是定義了和狀態相關的行爲的接口，二是擁有一個環境實例，用於在一定條件下修改環境角色的抽象狀態。

    NormalUser、 SilverUser、GoldUser以及DiamondUser就是具體狀態了。它們都實現了抽象狀態角色定義的接口。

    爲User轉化UserLevel的操作是在各個具體狀態中進行的。在這裏可以看到這種狀態的轉化是有序列的，這樣也只會有前後兩個狀態產生依賴。假設現在的會員系統中是沒有鑽石用戶的，那麼GoldUser的StateCheck()方法中應該是沒有什麼代碼的，即使以後再要加DiamondUser類，我們也只需要修改GoldUser的SateCheck()方法，以根據一定的規則來爲環境轉化狀態。

    在這裏，我們在環境中調用了StateCheck方法，在實際應用中，你可以根據需要在抽象狀態中引入模版方法，對外公開這個模版方法，並且在模版方法中調用行爲方法和轉化狀態的方法，當然，具體的行爲還是由具體狀態來實現的。
    
何時採用
    從代碼角度來說，如果一個類有多種狀態，並且在類內部通過的條件語句判斷的類狀態來實現不同行爲時候可以把這些行爲單獨封裝爲狀態類。
    從應用角度來說，如果一個對象有多種狀態，如果希望把對象狀態的轉化以及由不同狀態產生的行爲交給具體的狀態類去做，那麼可以考慮狀態模式。
    
實現要點
    在環境角色中擁有狀態角色的實例。
    在狀態角色中擁有環境角色的實例用於在具體狀態中修改環境角色的狀態。
    狀態對象之間的依賴可以通過加載外部配置的轉化規則表等方法來消除。
    狀態模式和策略模式的主要區別是，前者的行爲實現方式是由條件決定的，並且應當能不在客戶端干預的情況下自己遷移到合適的狀態，而後者的行爲實現方式是由客戶端選擇的，並且能隨時替換。
    
注意事項
    過多的狀態對象可能會增加系統負擔，可以考慮把各種狀態角色實現爲無狀態對象的享元，需要保存的額外狀態由環境角色進行統一管理和處理。