結合項目執行個體 回顧傳統設計模式（一）政策模式

蟲子以前在一家電商公司 會員的子產品在這裡分類很明确

不同的會員所具有的權限和行為不同，大多程式員會使用标準的oo技術，設計一個會員超類SuperUser，并讓各種商家會員繼承此超類

到這裡無可厚非，但是在下面個過程中你可以就慢慢體會政策模式與你在代碼裡不停寫邏輯判斷所帶來的差別有多大

所有的會員都具有下列行為

購物，評價，釋出商品

View Code

public abstract class SuperUser

    {

        public SuperUser()

        {

        }

        public void shopping()

            Console.WriteLine("shopping");

        public void Comment()

            Console.WriteLine("Comment");

        public abstract void Promote();

    }

    public class UserA : SuperUser

        public override void Promote()

            Console.WriteLine("推廣A類商品");

    public class UserB : SuperUser

            Console.WriteLine("推廣B類商品");

因為不同商家會員隻能推廣指定類型的商品是以這裡Promote方法抽象出來

好吧 現在我們來了一個新需求 對于B類的使用者 進行購物折價

加在什麼地方 超類？ 不 并不是所有的會員都擁有折價 邏輯判斷？ 是個方法 不過對于不斷需求的變更 在龐大臃腫的領域模型中 時間長了 也hold不住 更何況還不停有不同的商家會員分類加進來 并且在大型web架構中作為基站的程式不适合頻繁更新

既然這樣 利用接口如何 對改變關閉 對擴充開放

public interface discountBehavior

         void discount();

    public class diswithB : discountBehavior

        public void discount()

            Console.WriteLine("能打折扣呃");

    public class Nodis : discountBehavior

            Console.WriteLine("不能打折扣");

    public abstract class SuperUser

        public discountBehavior dcbehavior;

            dcbehavior.discount();

    public class UserA : SuperUser, discountBehavior

        public UserA()

            dcbehavior = new Nodis();

    public class UserB : SuperUser, discountBehavior

        public UserB()

            dcbehavior = new diswithB();

下面我們再來試試動态設定行為

在超類中加個方法

 public void setdiscountBehavior(discountBehavior dh)

            dcbehavior = dh;

這樣就可以“随時”調用這個方法 改變會員的行為

總結：

政策模式：針對接口程式設計，而不是針對實作程式設計。多用組合少用繼承。政策模式定義了算法簇，分别封裝起來，讓它們之間可以互相替換，此模式讓算法的變化獨立于使用算法的客戶。

本文轉自 熬夜的蟲子  51CTO部落格，原文連結:http://blog.51cto.com/dubing/712402