結合項目執行個體 回顧傳統設計模式（八）模闆方法模式

模闆方法定義了一個算法的步驟，并允許子類為一個或多個步驟提供實作。

普通的設計算法由實作類直接控制，在很多功能類似的對象中存在重複。并且由于類的組織方式不具有彈性，是以往往新加入新的相似子產品時需要作大量備援的步驟。

我們還是那電商的訂單送出來說事 ~ ~

/// <summary>

    /// 模闆類

    /// </summary>

    public abstract class OrderSubmit

    {

        public OrderSubmit()

        {

            //檢查購物車

            CheckCart();

            //檢查支付方式

            CheckPaytype();

            //檢查使用者位址

            CheckAddress();

            //送出訂單

            SubmitOrderInfo();

            //鈎子 根據子類是否需要來實作

            if (hookflag())

            {

                //生成發票

                CreateInvoice();

            }

        }

        public abstract void CheckCart();

        public abstract void CheckPaytype();

        public void CreateInvoice()

            //生成發票具體方法

        public void CheckAddress()

            //使用者位址檢查

        public void SubmitOrderInfo()

            //訂單送出詳細

        public bool hookflag()

            return true;

    }

    /// <summary>

    /// 主站訂單送出

    public class webOrderSubmit : OrderSubmit

        public override void CheckCart()

            //檢查屬于網站的購物車資訊

        public override void CheckPaytype()

            //檢查屬于網站的支付方式

        public  void CreateInvoice()

            //生成發票

    /// 移動終端訂單送出

    public class MoblieOrderSubmit : OrderSubmit

            //檢查屬于移動終端的購物車資訊

            //檢查屬于動終端的支付方式

        //不要發票

            return false;

總結：模闆方法模式在一個方法中定義一個算法的骨架，而将一些步驟延遲到子類中。模闆方法使得子類可以在不改變算法結構的情況下，重新定義算法中的某些步驟。和其他模式相比，模闆方法由子類決定如何實作算法中得步驟；政策模式則是封裝可互換的行為，然後使用委托來決定要采用哪一個行為；工廠模式由子類決定執行個體化哪個具體類。

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