設計模式--工廠和策略的區別

來源:互聯網
上載者:User

標籤:blog   http   io   os   使用   ar   div   art   sp   

名詞理解:

工廠(Factory)模式我們可以做如下理解,假設有一個Audi的公司生產汽車(似乎也不用假設了),它掌握一項核心的技術就是生產汽車,另一方面,它生產的汽車是有不同型號的,並且在不同的生產線上進行組裝。當客戶通過銷售部門進行預定後,Audi公司將在指定的生產線上為客戶生產出它所需要的汽車。

策略(Strategy)模式在結構上與原廠模式類似,唯一的區別是原廠模式執行個體化一個產品的操作是在服務端來做的,換句話說用戶端傳達給服務端的只是某種標識,服務端根據該標識執行個體化一個對象。而策略模式的用戶端傳達給服務端的是一個執行個體,服務端只是將該執行個體拿過去在服務端的環境裡執行該執行個體的方法。這就好比一個對汽車不甚瞭解的人去買車,他在那一比劃,說要什麼什麼樣的,銷售部門根據他的這個“比劃”來形成一份訂單,這就是原廠模式下的工作方式。而策略模式下那個顧客就是個行家,他自己給出了訂單的詳細資料,銷售部門只是轉了一下手就交給生產部門去做了。通過兩相對比,我們不難發現,採用原廠模式必須提供足夠靈活的銷售部門,如果使用者有了新的需求,銷售部門必須馬上意識到這樣才可以做出合適的訂單。所以倘一款新車出來了,生產部門和銷售部門都需要更新,對顧客來說也需要更新對新車的描述所以需要改動的地方有三處。而策略模式中的銷售部門工作比較固定,它只負責接受訂單並執行特定的幾個操作。當一款新車出來時,只需要對服務端的生產部門和用戶端的代碼進行更新,而不需要更新銷售部門的代碼。

支援人員:

簡單工廠和策略的基礎都是因為物件導向的封裝與多態。他們實現的思想都是先設定一個抽象的模型並從該模型派生出符合不同客戶需求的各種方法,並加以封裝。

模型:

Audi公司的產品有A6, A4, TT, R8...我們如果將每種車的生產做一個方法,那麼我們的模型結構應該是這樣的



namespace ConsoleApplication5

{

    class Audi

    {

        public void CreateA4()

        {

            //Do someting

        }

        public void CreateA6()

        {

            //Do something

        }

        public void CreateTT()

        {

            //Do something

        }

    }

}

 

 

設想一下如果Audi出了一款新車,那麼我們必須要在Audi這個類裡邊添加新的方法,這就要求總公司提供對Audi這個類的修改許可權,如果新車項目的負責人對其他車型的負責人有什麼意見,
它可以輕而易舉改亂他們的代碼,讓他們的工作陷入癱瘓(當然現實中沒有人會這麼幹)。我們的目標是新生產線的項目負責人只有許可權對自己的項目情況作出修改,除此之外他一無所知。
我們可以考慮如下的模型結構
Code
這種結構的好處是將每一條生產線進行了封裝,在必要的情況下可以使他們的原始碼在彼此之間不可見,這一點正是我們所希望看到的。另外如果每條生產線涉及的代碼量很大,
這種結構也可以避免重複編譯,我們只需要對新增加的生產線進行編譯而之前的生產線我們甚至連動都不需要動。到目前為止,簡單原廠模式和策略模式沒有什麼區別。
原廠模式和策略模式的區別在於執行個體化一個對象的位置不同,對原廠模式而言,執行個體化對象是放在服務端的,下面這個類就是用來做這個的。

    class SelectCarFactoryPattern
    {
        static BaseFactory bf = null;
        public static void OrderCar(string strCarType)
        {
            switch (strCarType)
            {
                case "A6":
                    bf = new A6Factory();
                    bf.MakeCar();
                    break;
                case "A4":
                    bf = new A4Factory();
                    bf.MakeCar();
                    break;
                case "R8":
                    bf = new R8Factory();
                    bf.MakeCar();
                    break;
                default:
                    Console.WriteLine("Error car");
                    break;
            }
        }
而策略模式執行個體化對象的操作在用戶端,服務端的“銷售部門”只負責傳遞該對象,並在服務端的環境裡執行特定的操作。正如下面這個類所做的

class SelectCarStrategyPattern
    {
        BaseFactory carFactory = null;
        public SelectCarStrategyPattern(BaseFactory carFactory)
        {
            this.carFactory = carFactory;
        }
        public void OrderCar()
        {
            this.carFactory.MakeCar();
        }
    }
下面是服務端在兩種模式下執行個體化一個對象並進行操作的樣本,原廠模式要求服務端的銷售部門足夠靈敏,而策略模式由於對策略進行了封裝,所以他的銷售部門比較傻,需要客戶提供
足夠能區分使用哪種策略的參數,而這最好的就是該策略的執行個體了。
Code

設計模式--工廠和策略的區別(轉)

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在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.