本筆記摘抄自：記錄一下學習過程以備後續查用。
在現實生活中，我們經常會遇到一些構成比較複雜的物品。比如電腦，是由cpu、主機板、記憶體條、硬碟、顯示卡、機箱等組裝而成的。手機也是複雜物品，由主機板、各種晶元、ram、rom、攝像頭等部件組成。但是無論是電腦還是手機，它們的組裝過程是固定的。拿手機來說，組裝流水線是固定的、不變的，但是把不同的主機板和其它元件組裝在一起就會生產出不同型號的手機。那麼在軟體系統中是不是也會存在這樣的物件呢？答案是肯定的。在軟體系統中我們也會遇到類似的複雜物件，並且這個複雜物件的各個部分按照一定的演算法組合在一起，此時該物件的建立工作就可以使用builder模式了，下面讓我們詳細看看這個模式吧。
建造者模式（也叫生成器模式）：英文名稱--builder pattern；分類--建立型。
2.1、動機（motivate）
在軟體系統中，有時候面臨著「乙個複雜物件」的建立工作，其通常由各個部分的子物件用一定的演算法構成。由於需求的變化，這個複雜物件的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的演算法卻相對穩定。如何應對這種變化？如何提供一種「封裝機制」來隔離出「複雜物件的各個部分」的變化，從而保持系統中的「穩定構建演算法」不隨著需求改變而改變？
2.2、意圖（intent）
將乙個複雜物件的構建與其表示相分離，使得同樣的構建過程可以建立不同的表示。——《設計模式》gof
2.3、結構圖（structure）
2.4、模式的組成
1）抽象建造者角色（builder）：為建立乙個product物件的各個部件指定抽象介面，以規範產品物件的各個組成部分的建造。一般而言，此角色規定要實現複雜物件的哪些部件的建立，並不涉及具體的物件部件的建立。
2）具體建造者（concretebuilder）
i、實現builder的介面以構造和裝配該產品的各個部件，即實現抽象建造者角色builder的方法。
ii、定義並明確它所建立的表示，即針對不同的商業邏輯，具體化複雜物件的各個部分的建立。
iii、提供乙個檢索產品的介面。
iv、構造乙個使用builder介面的物件，即在指導者的呼叫下建立產品例項。
3）指導者（director）：呼叫具體建造者角色以建立產品物件的各個部分。指導者並沒有涉及具體產品類的資訊，真正擁有具體產品的資訊是具體建造者物件。它只負責保證物件各部分完整建立或按某種順序建立。
4）產品角色（product）：建造中的複雜物件。它要包含那些定義元件的類，包括將這些元件裝配成產品的介面。
2.5、建造者模式的具體實現
現在人們生活水平都提高了，家家都有了家庭轎車，那今天我們就以汽車組裝為例來說明builder模式的實現。
classview codeprogram
public
void
show()
console.writeline(
"小轎車組裝完畢。");}}
//////
抽象建造者，它定義了要建立什麼部件和最後建立的結果，但是不是組裝的的型別，切記。
/// public
abstract
class
builder
//////
具體建立者，具體車型的建立者，例如：別克。
/// public
sealed
class
buickbuilder : builder
public
override
void
buildsalooncarwheel()
public
override
void
buildsalooncarengine()
public
override
salooncar getsalooncar()
}//////
具體建立者，具體車型的建立者，例如：奧迪
/// public
sealed
class
aodibuilder : builder
public
override
void
buildsalooncarwheel()
public
override
void
buildsalooncarengine()
public
override
salooncar getsalooncar()
}//////
這個型別才是組裝的
///construct方法裡面的實現就是建立複雜物件固定演算法的實現，該演算法是固定的或者說是相對穩定的。
///這個人當然就是老闆了，也就是建造者模式中的指揮者。
/// public
class
director
}static
void main(string
args)
}
執行結果如下：
在建造者模式中，指揮者是直接與客戶端打交道的。指揮者將客戶端建立產品的請求轉換為對各個部件的建造請求，再將這些請求委派給具體的建造者角色，而具體的建造者角色是完成具體產品的構建工作的，卻不為客戶所知道。
建造者模式主要用於「分步驟來構建乙個複雜的物件」，其中「分步驟」是乙個固定的組合過程，而複雜物件的各個部分是經常變化的。產品不需要抽象類，因為建造者模式建立出來的最終產品可能差異很大，所以不大可能提煉出乙個抽象產品類。 在前面文章中介紹的抽象工廠模式解決了「多系列產品」的需求變化，而建造者模式解決的是 「產品部分」 的需要變化。由於建造者隱藏了具體產品的組裝過程，所以要改變乙個產品的內部表示，只需要再實現乙個具體的建造者就可以了，從而能很好地應對產品組成部件的需求變化。
3.1、建造者模式的優點
1）使用建造者模式可以使客戶端不必知道產品內部組成的細節。
2）具體的建造者類之間是相互獨立的，容易擴充套件。
3）由於具體的建造者是獨立的，因此可以對建造過程逐步細化，而不對其他的模組產生任何影響。
3.2、建造者模式的缺點
1）產生多餘的build物件以及dirextor類。
3.3、建立者模式的使用場合
1）當建立複雜物件的演算法應該獨立於該物件的組成部分以及它們的裝配方式時。
2）相同的方法，不同的執行順序，產生不同的事件結果時。
3）多個部件或零件，都可以裝配到乙個物件中，但是產生的執行結果又不相同時。
4）產品類非常複雜，或者產品類中的呼叫順序不同產生了不同的效能。
5）建立一些複雜的物件時，這些物件的內部組成構件間的建造順序是穩定的，但是物件的內部組成構件面臨著複雜的變化。
微軟的類庫裡面大量使用了設計模式，如果要想學習設計模式，仔細看看微軟的類庫是很有幫助的。今天的設計模式在fcl裡面也有實現，該型別的名字是system.text.stringbuilder(存在於mscorlib.dll程式集中)，它就是乙個建造者模式的實現，從名稱也可以看出來。不過它的實現屬於建造者模式的演化，此時的建造者模式沒有指揮者角色和抽象建造者角色，stringbuilder類既扮演著具體建造者的角色，也同時扮演了指揮者和抽象建造者的角色。
需要重申的是，學習設計模式不能死學，就像stringbuilder一樣，他和gof23種設計模式中定義的情形有很大的不同，但是它也是builder模式，因為它要解決的問題和使用場景是吻合的。我們寫**的時候，不要太居於形式，要看使用的契機和模式是否吻合，根據具體的情況我們的模式也會發生變化。當我們看得越多也寫得越多的時候，變化就越自然了。
設計模式4 建造者模式
首先說說建造者模式要解決乙個什麼樣的問題 流程控制,即保證方法先後順序正確且沒有遺漏.用於靈活指導操作細節.建造者模式包括 乙個導演類 用於規定操作順序 乙個建造者介面 用於規定建造者的操作 具體的建造者 建造者的具體實現類 例如 public class buildertest class fil...
4 設計模式 建造者模式
前段時間一直忙於考證，沒有整理，開啟部落格感覺又好像過了很久的樣子，哎，鬆懈時間過得真快，今天整理一波建造者模式。從字面意思建造者模式更傾向於建造。例如計算機包含滑鼠，鍵盤，耳機，音響，印表機等等硬體裝置。這是乙個相對比較複雜的物件。而我們要建立的是計算機這個整體，如果採用工廠模式就沒那麼專業。因為...
設計模式 4 建造者模式
說明 將很多事情，一件一件的按順序組裝形成，stringbuilding就是建造者模式。場景 當乙個流程由很多功能組成，可以直接使用，然後每個實現就好。實現 public class customer 組裝電腦需要的步驟，這裡只組裝了cpu,硬碟 public abstract class ling...