簡單原廠模式和策略模式的區別

來源:互聯網
上載者:User

標籤:簡單原廠模式和策略模式的區別 設計模

直接上代碼:

簡單原廠模式:

------------------------------一個抽象類別   --------------------------
abstract class AbsClass
{
    //抽象方法:提供一些列的演算法操作
    public abstract void acceptCash(string org);
}

------------------------------2個實作類別   --------------------------

//繼承自抽象類別
class A:AbsClass
{
    //具體方法:提供一些列的演算法操作
    public override double acceptCash(string org)

{

         Console.WriterLine("A類方法");

  }
}

//繼承自抽象類別
class B:AbsClass
{
    //具體方法:提供一些列的演算法操作
    public override double acceptCash(string org)

{

         Console.WriterLine("B類方法");

  }
}

------------------------------簡單工廠類   --------------------------

//現金收取工廠
class CashFactory
{
    //根據條件返回相應的對象
    public static AbsClass createCashAccept(stringtype)
    {
        AbsClass cs = null;
        switch (type)
        {
            case "A":
                cs = new Al();
                break;
            case "B":
                cs = new B();
                break;
            case "...":
                ........ ....
                break;
        }
        return cs;
    }
}

 

用戶端調用:

/利用簡單原廠模式根據下拉選擇框,產生相應的對象
AbsClass csuper = CashFactory.createCashAccept("A");// 通過傳入type 就可以得到具體的實作類別,就好比:你去機場,你直接跟你秘書說,我們開車去機場,這個時候你秘書開車載我去,你負責坐車到機場就可以了。

AbsClass csuper= CashFactory.createCashAccept("B"); //或者 秘書去叫出租車 我們打車去

 


------------------------------策略模式:   --------------------------

 前面的類沒有任何變化,只是把Factory變成了CaseContext策略類

//策略Context
class CashContext
{
    //聲明一個現金收費父類對象
    private AbsClass cs;

    //設定策略行為,參數為具體的現金收費子類(正常,打折或返利)
    public CashContext(AbsClass csuper)
    {
        this.cs = csuper;
    }

    //得到現金促銷計算結果(利用了多態機制,不同的策略行為導致不同的結果)
    public double GetResult(double money)
    {
        return cs.acceptCash(money);
    }
}

用戶端調用:

AbsClass cc = null;
   switch (cbxType.SelectedItem.ToString())
            {
                case "A":
                    cc = new CashContext(new A()); //同樣是去機場,此時:自己開車去
                    break;
                case "B":
                    cc = new CashContext(new B());//或者自己打車去
                    break;
                case "...":
                    ... ....
                    break;
            }

最後概括總結一下:

策略模式和簡單原廠模式看起來非常相似,都是通過多態來實現不同子類的選取,這種思想應該是從程式的整體來看得出的。如果從使用這兩種模式的角度來看的話,我們會發現在簡單原廠模式中我們只需要傳遞相應的條件就能得到想要的一個對象(告訴別人我要幹嘛、別人去做),然後通過這個對象實現演算法的操作。而策略模式,使用時必須首先建立一個想使用的類對象(自己去 做),然後將該對象最為參數傳遞進去,通過該對象調用不同的演算法。在簡單原廠模式中實現了通過條件選取一個類去執行個體化對象,策略模式則將選取相應對象的工作交給模式的使用者,它本身不去做選取工作。

結合上面的代碼和下面的釋義不難看出,其實兩個的差別很微妙,Factory是直接建立具體的對象並用該對象去執行相應的動作,而Context將這個操作給了Context類,沒有建立具體的對象,實現的代碼的進一步封裝,用戶端代碼並不需要知道具體的實現過程。

當然用的最多的還是兩者的結合使用

------------------------------策略模式和簡單原廠模式:   --------------------------

 前面的類沒有任何變化,只是把Factory變成了CaseContext策略類

//策略Context
class CashContext
{
    //聲明一個現金收費父類對象
    private AbsClass cs;

  public CashContext(String typr)
    {
        switch (type)     //跟秘書打個招呼 我要去機場
             {
                case "A":
                    cc = new CashContext(new A()); //同樣是去機場,此時:自己開車去
                    break;
                case "B":
                    cc = new CashContext(new B());//或者自己打車去
                    break;
                case "...":
                    ... ....
                    break;
             }

  }

    //得到現金促銷計算結果(利用了多態機制,不同的策略行為導致不同的結果)
    public double GetResult(double money)
    {
        return cs.acceptCash(money);
    }
}

用戶端調用:

CashContext context=CashContext("A");

double a=context.GetResult(double money);

總結:簡單原廠模式:只需要發出命令,由他人去實現,策略模式:不僅僅要發出命令,還得由自己親自去做。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.