概述

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

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

　　意圖

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

　　模型圖

　　生活中的例子

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

　　實(shí)現(xiàn)過(guò)程圖解

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

　　客戶端：顧客。想去買一套套餐（這里面包括漢堡，可樂(lè)，薯?xiàng)l），可以有1號(hào)和2號(hào)兩種套餐供顧客選擇。

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

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

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

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

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

    

    

    

    

        

        

            FoodManager foodmanager 

            Builder instance;

            Console.WriteLine(

            

            

            instance 

            foodmanager.Construct(instance);

        }

    }

}

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

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