系列文章導航：

四大發明之活字印刷——面向對象思想的勝利

小菜編程成長記（一 面試受挫——代碼無錯就是好？）

小菜編程成長記（二 代碼規范、重構）

小菜編程成長記（三 復制VS復用）

小菜編程成長記（四 業務的封裝）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（六 工廠不好用了？）

小菜編程成長記（七 用“策略模式”是一種好策略）

小菜編程成長記（八 反射——程序員的快樂?。?/a>

小菜編程成長記（九 會修電腦不會修收音機？——聊設計模式原則）

小菜編程成長記（十 三層架構，分層開發）

小菜編程成長記（十一 無熟人難辦事？——聊設計模式迪米特法則）

小菜編程成長記（十二 有了門面，程序員的程序會更加體面?。?/a>

小菜編程成長記（十三 設計模式不能戲說！設計模式怎就不能戲說？）

（續上篇）
　　小菜心里想：“大鳥要我做的是一個商場收銀軟件，營業員根據客戶購買商品單價和數量，向客戶收費。這個很簡單，兩個文本框，輸入單價和數量，再用個列表框來記錄商品的合計，最終用一個按鈕來算出總額就可，對，還需要一個重置按鈕來重新開始，不就行了？！”

代碼樣例（可使用）：

　　商場收銀系統v1.0關鍵代碼如下：

Code
//聲明一個double變量total來計算總計
double total = 0.0d;
private void btnOk_Click(object sender, EventArgs e)
{
    //聲明一個double變量totalPrices來計算每個商品的單價（txtPrice）*數量(txtNum)后的合計
    double totalPrices=Convert.ToDouble(txtPrice.Text) * Convert.ToDouble(txtNum.Text);
    //將每個商品合計計入總計
    total = total + totalPrices;
    //在列表框中顯示信息
    lbxList.Items.Add("單價："+txtPrice.Text+" 數量："+txtNum.Text+" 合計："+totalPrices.ToString());
    //在lblResult標簽上顯示總計數
    lblResult.Text = total.ToString();
}

系列文章導航：

四大發明之活字印刷——面向對象思想的勝利

小菜編程成長記（一 面試受挫——代碼無錯就是好？）

小菜編程成長記（二 代碼規范、重構）

小菜編程成長記（三 復制VS復用）

小菜編程成長記（四 業務的封裝）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（六 工廠不好用了？）

小菜編程成長記（七 用“策略模式”是一種好策略）

小菜編程成長記（八 反射——程序員的快樂！）

小菜編程成長記（九 會修電腦不會修收音機？——聊設計模式原則）

小菜編程成長記（十 三層架構，分層開發）

小菜編程成長記（十一 無熟人難辦事？——聊設計模式迪米特法則）

小菜編程成長記（十二 有了門面，程序員的程序會更加體面！）

小菜編程成長記（十三 設計模式不能戲說！設計模式怎就不能戲說？）

“這下可以了吧，只要我事先把商場可能的打折都做成下拉選擇框的項，要變化的可能性就小多了。”小菜說道。
      “這比剛才靈活性上是好多了，不過重復代碼很多，像Convert.ToDouble（），你這里就寫了8遍，而且4個分支要執行的語句除了打折多少以外幾乎沒什么不同，應該考慮重構一下。不過還不是最主要的，現在我的需求又來了，商場的活動加大，需要有滿300返100的促銷算法，你說怎么辦？”
       “滿300返100，那要是700就要返200了？這個必須要寫函數了吧？”
       “小菜呀，看來之前教你的白教了，這里面看不出什么名堂嗎？”   
       “哦！我想起來了，你的意思是簡單工廠模式是吧，對的對的，我可以先寫一個父類，再繼承它實現多個打折和返利的子類，利用多態，完成這個代碼。”
       “你打算寫幾個子類？”
       “根據需求呀，比如8折、7折、5折、滿300送100、滿200送50……要幾個寫幾個。”
       “小菜又不動腦子了，有必要這樣嗎？如果我現在要3折，我要滿300送80，你難道再去加子類？你不想想看，這當中哪些是相同的，哪些是不同的？”
       “對的，這里打折基本都是一樣的，只要有個初始化參數就可以了。滿幾送幾的，需要兩個參數才行，明白，現在看來不麻煩了。”
        “面向對象的編程，并不是類越多越好，類的劃分是為了封裝，但分類的基礎是抽象，具有相同屬性和功能的對象的抽象集合才是類 。打一折和打九折只是形式的不同，抽象分析出來，所有的打折算法都是一樣的，所以打折算法應該是一個類。好了，空話已說了太多，寫出來再是真的懂。”

　　 大約1個小時后，小菜交出了第三份的作業

　　商場收銀系統v1.3關鍵代碼如下：

Code
//現金收取父類
abstract class CashSuper
{
    //抽象方法：收取現金，參數為原價，返回為當前價
    public abstract double acceptCash(double money);
}
//正常收費，繼承CashSuper
class CashNormal : CashSuper
{
    public override double acceptCash(double money)
    {
        return money;
    }
}
//打折收費，繼承CashSuper
class CashRebate : CashSuper
{
    private double moneyRebate = 1d;
    //初始化時，必需要輸入折扣率,如八折，就是0.8
    public CashRebate(string moneyRebate)
    {
        this.moneyRebate = double.Parse(moneyRebate);
    }

    public override double acceptCash(double money)
    {
        return money * moneyRebate;
    }
}
//返利收費，繼承CashSuper
class CashReturn : CashSuper
{
    private double moneyCondition = 0.0d;
    private double moneyReturn = 0.0d;
    //初始化時必須要輸入返利條件和返利值，比如滿300返100，則moneyCondition為300，moneyReturn為100
    public CashReturn(string moneyCondition, string moneyReturn)
    {
        this.moneyCondition = double.Parse(moneyCondition);
        this.moneyReturn = double.Parse(moneyReturn);
    }

    public override double acceptCash(double money)
    {
        double result = money;
        //若大于返利條件，則需要減去返利值
        if (money >= moneyCondition)
            result = money - Math.Floor(money / moneyCondition) * moneyReturn;

        return result;
    }
}
//現金收取工廠
class CashFactory
{
    //根據條件返回相應的對象
    public static CashSuper createCashAccept(string type)
    {
        CashSuper cs = null;
        switch (type)
        {
            case "正常收費":
                cs = new CashNormal();
                break;
            case "滿300返100":
                CashReturn cr1 = new CashReturn("300", "100");
                cs = cr1;
                break;
            case "打8折":
                CashRebate cr2 = new CashRebate("0.8");
                cs = cr2;
                break;
        }
        return cs;
    }
}

//客戶端窗體程序（主要部分）
CashSuper csuper;//聲明一個父類對象
double total = 0.0d;
private void btnOk_Click(object sender, EventArgs e)
{
    //利用簡單工廠模式根據下拉選擇框，生成相應的對象
    csuper = CashFactory.createCashAccept(cbxType.SelectedItem.ToString());
    double totalPrices=0d;
    //通過多態，可以得到收取費用的結果
    totalPrices = csuper.acceptCash(Convert.ToDouble(txtPrice.Text) * Convert.ToDouble(txtNum.Text));
    total = total + totalPrices;
    lbxList.Items.Add("單價：" + txtPrice.Text + " 數量：" + txtNum.Text + " "+cbxType.SelectedItem+ " 合計：" + totalPrices.ToString());
    lblResult.Text = total.ToString();
}

系列文章導航：

四大發明之活字印刷——面向對象思想的勝利

小菜編程成長記（一 面試受挫——代碼無錯就是好？）

小菜編程成長記（二 代碼規范、重構）

小菜編程成長記（三 復制VS復用）

小菜編程成長記（四 業務的封裝）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（五 體會簡單工廠模式的美妙）

小菜編程成長記（六 工廠不好用了？）

小菜編程成長記（七 用“策略模式”是一種好策略）

小菜編程成長記（八 反射——程序員的快樂?。?/a>

小菜編程成長記（九 會修電腦不會修收音機？——聊設計模式原則）

小菜編程成長記（十 三層架構，分層開發）

小菜編程成長記（十一 無熟人難辦事？——聊設計模式迪米特法則）

小菜編程成長記（十二 有了門面，程序員的程序會更加體面！）

小菜編程成長記（十三 設計模式不能戲說！設計模式怎就不能戲說？）

　　“大鳥，搞定，這次無論你要怎么改，我都可以簡單處理就行了。”小菜自信滿滿的說。
      “是嗎，我要是需要打5折和滿500送200的促銷活動，如何辦？”
      “只要在現金工廠當中加兩個條件，在界面的下拉選項框里加兩項，就OK了。”
      “現金工廠？！你當是生產鈔票呀。是收費對象生成工廠才準確。說得不錯，如果我現在需要增加一種商場促銷手段，滿100積分10點，以后積分到一定時候可以領取獎品如何做？”
      “有了工廠，何難？加一個積分算法，構造方法有兩個參數：條件和返點，讓它繼承CashSuper，再到現金工廠，哦，不對，是收—費—對—象—生—成—工—廠里加滿100積分10點的分支條件，再到界面稍加改動，就行了。”
      “嗯，不錯，那我問你，如果商場現在需要拆遷，沒辦法，只能跳樓價銷售，商場的所有商品都需要打8折，打折后的價錢再每種商品滿300送50，最后計總價的時候，商場還滿1000送200，你說如何辦？”
      “搞沒搞錯哦，這商場不如白送得了，哪有這樣促銷的？老板跳樓時估計都得赤條條的了。”
      “商場大促銷你還不高興呀！當然，你是軟件開發者，客戶老是變動需求的確不爽，但你不能不讓客戶提需求呀，我不是說過嗎，需求的變更是必然！所以開發者應該的是考慮如何讓自己的程序更能適應變化，而不是抱怨客戶的無理，客戶不會管程序員加班時的汗水，也不相信程序員失業時的眼淚，因為客戶自己正在為自己的放血甩賣而流淚呀。”
      大鳥接著說：“簡單工廠模式雖然也能解決這個問題，但的確不是最好的辦法，另外由于商場是可能經常性的更改打折額度和返利額度，每次更改都需要改寫代碼重新編譯部署真的是很糟糕的處理方式，面對算法的時常變動，應該有更好的辦法。好好去研究一下設計模式吧，推薦你看一本書，《深入淺出設計模式》，或許你看完第一章，就會有解決辦法了。”
        小菜進入了沉思中……

（待續）本例C#源代碼
　　另：建議大家去閱讀《深入淺出設計模式》，第一章下載，本人非常喜歡這本書的風格，這是真正的做到了深入淺出呀。我也希望自己可以用類似的方式講述問題。

　　本文還有一個用意是對一些初學者，可以考慮一下大鳥提出的問題，在我的下一篇《小菜編程成長記八》出來之前，改寫我的源代碼，實現更靈活更方便的商場收銀程序共享給大家討論，或許您寫的東東比我寫的還要好，那樣就大家都有提高了。程序不是看出來的，是寫出來的。好好加油！

NET技術：小菜編程成長記（六 工廠不好用了？），轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。