概述

　　在軟件系統(tǒng)中，有時候面臨著“一個復(fù)雜對象”的創(chuàng)建工作，其通常由各個部分的子對象用一定的算法構(gòu)成；由于需求的變化，這個復(fù)雜對象的各個部分經(jīng)常面臨著劇烈的變化，但是將它們組合在一起的算法確相對穩(wěn)定。如何應(yīng)對這種變化？如何提供一種“封裝機制”來隔離出“復(fù)雜對象的各個部分”的變化，從而保持系統(tǒng)中的 “穩(wěn)定構(gòu)建算法”不隨著需求改變而改變？這就是要說的建造者模式。

　　本文通過現(xiàn)實生活中的買KFC的例子，用圖解的方式來詮釋建造者模式。

　　意圖

　　將一個復(fù)雜的構(gòu)建與其表示相分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。

　　模型圖

　　生活中的例子

　　生成器模式將復(fù)雜對象的構(gòu)建與對象的表現(xiàn)分離開來，這樣使得同樣的構(gòu)建過程可以創(chuàng)建出不同的表現(xiàn)。這種模式用于快餐店制作兒童餐。典型的兒童餐包括一個主食，一個輔食，一杯飲料和一個玩具（例如漢堡、炸雞、可樂和玩具車）。這些在不同的兒童餐中可以是不同的，但是組合成兒童餐的過程是相同的。無論顧客點的是漢堡，三名治還是雞肉，過程都是一樣的。柜臺的員工直接把主食，輔食和玩具放在一起。這些是放在一個袋子中的。飲料被倒入杯中，放在袋子外邊。這些過程在相互競爭的餐館中是同樣的。

　　實現(xiàn)過程圖解

　　在這里我們還是以去KFC店買套餐為例子，示意圖如下：

　　客戶端：顧客。想去買一套套餐（這里面包括漢堡，可樂，薯條），可以有1號和2號兩種套餐供顧客選擇。

　　指導(dǎo)者角色：收銀員。知道顧客想要買什么樣的套餐，并告訴餐館員工去準(zhǔn)備套餐。

　　建造者角色：餐館員工。按照收銀員的要求去準(zhǔn)備具體的套餐，分別放入漢堡，可樂，薯條等。

　　產(chǎn)品角色：最后的套餐，所有的東西放在同一個盤子里面。
　　
　　下面開始我們的買套餐過程。

　　1．客戶創(chuàng)建Derector對象，并用它所想要的Builder對象進行配置。顧客進入KFC店要買套餐，先找到一個收銀員，相當(dāng)于創(chuàng)建了一個指導(dǎo)者對象。這位收銀員給出兩種套餐供顧客選擇：1普通套餐，2黃金套餐。完成的工作如時序圖中紅色部分所示。

　　程序?qū)崿F(xiàn)：

    

    

    

    

        

        

            FoodManager foodmanager 

            Builder instance;

            Console.WriteLine(

            

            

            instance 

            foodmanager.Construct(instance);

        }

    }

}

NET技術(shù)：.NET設(shè)計模式：建造者模式（Builder Pattern），轉(zhuǎn)載需保留來源！

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