溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
在軟件系統中，有時需要創建一個復雜對象，并且這個復雜對象由其各部分子對象通過一定的步驟組合而成。例如一個采購系統中，如果需要采購員去采購一批電腦時，在這個實際需求中，電腦就是一個復雜的對象，它是由CPU、主板、硬盤、顯卡、機箱等組裝而成的，如果此時讓采購員一臺一臺電腦去組裝的話真是要累死采購員了，這里就可以采用建造者模式來解決這個問題，我們可以把電腦的各個組件的組裝過程封裝到一個建造者類對象里，建造者只要負責返還給客戶端全部組件都建造完畢的產品對象就可以了。然而現實生活中也是如此的，如果公司要采購一批電腦，此時采購員不可能自己去買各個組件并把它們組織起來，此時采購員只需要像電腦城的老板說自己要采購什么樣的電腦就可以了，電腦城老板自然會把組裝好的電腦送到公司。下面就以這個例子來展開建造者模式的介紹。
在這個例子中，電腦城的老板是直接與客戶（也就是指采購員）聯系的，然而電腦的組裝是由老板指揮裝機人員去把電腦的各個部件組裝起來，真真負責創建產品（這里產品指的就是電腦）的人就是電腦城的裝機人員。理清了這個邏輯過程之后，下面就具體看下如何用代碼來表示這種現實生活中的邏輯過程：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
/// <summary>
/// 以組裝電腦為例子
/// 每臺電腦的組成過程都是一致的，但是使用同樣的構建過程可以創建不同的表示(即可以組裝成不一樣的電腦，配置不一樣)
/// 組裝電腦的這個場景就可以應用建造者模式來設計
/// </summary>
namespace 設計模式之建造者模式
{
/// <summary>
/// 客戶類
/// </summary>
class Customer
{
static void Main(string[] args)
{
// 客戶找到電腦城老板說要買電腦，這里要裝兩臺電腦
// 創建指揮者和構造者
Director director = new Director();
Builder b1 = new ConcreteBuilder1();
Builder b2 = new ConcreteBuilder2();
// 老板叫員工去組裝第一臺電腦
director.Construct(b1);
// 組裝完，組裝人員搬來組裝好的電腦
Computer computer1 = b1.GetComputer();
computer1.Show();
// 老板叫員工去組裝第二臺電腦
director.Construct(b2);
Computer computer2 = b2.GetComputer();
computer2.Show();
Console.Read();
}
}
/// <summary>
/// 小王和小李難道會自愿地去組裝嘛，誰不想休息的，這必須有一個人叫他們去組裝才會去的
/// 這個人當然就是老板了，也就是建造者模式中的指揮者
/// 指揮創建過程類
/// </summary>
public class Director
{
// 組裝電腦
public void Construct(Builder builder)
{
builder.BuildPartCPU();
builder.BuildPartMainBoard();
}
}
/// <summary>
/// 電腦類
/// </summary>
public class Computer
{
// 電腦組件集合
private IList<string> parts = new List<string>();
// 把單個組件添加到電腦組件集合中
public void Add(string part)
{
parts.Add(part);
}
public void Show()
{
Console.WriteLine("電腦開始在組裝.......");
foreach (string part in parts)
{
Console.WriteLine("組件"+part+"已裝好");
}
Console.WriteLine("電腦組裝好了");
}
}
/// <summary>
/// 抽象建造者，這個場景下為 "組裝人" ，這里也可以定義為接口
/// </summary>
public abstract class Builder
{
// 裝CPU
public abstract void BuildPartCPU();
// 裝主板
public abstract void BuildPartMainBoard();
// 當然還有裝硬盤，電源等組件，這里省略
// 獲得組裝好的電腦
public abstract Computer GetComputer();
}
/// <summary>
/// 具體創建者，具體的某個人為具體創建者，例如：裝機小王啊
/// </summary>
public class ConcreteBuilder1 : Builder
{
Computer computer = new Computer();
public override void BuildPartCPU()
{
computer.Add("CPU1");
}
public override void BuildPartMainBoard()
{
computer.Add("Main board1");
}
public override Computer GetComputer()
{
return computer;
}
}
/// <summary>
/// 具體創建者，具體的某個人為具體創建者，例如：裝機小李啊
/// 又裝另一臺電腦了
/// </summary>
public class ConcreteBuilder2 : Builder
{
Computer computer = new Computer();
public override void BuildPartCPU()
{
computer.Add("CPU2");
}
public override void BuildPartMainBoard()
{
computer.Add("Main board2");
}
public override Computer GetComputer()
{
return computer;
}
}
}上面代碼中都有詳細的注釋代碼，這里就不過多解釋，大家可以參考代碼和注釋來與現實生活中的例子做對比，下圖展示了上面代碼的運行結果：
介紹完了建造者模式的具體實現之后嗎，下面具體看下建造者模式的具體定義是怎樣的。
建造者模式（Builder Pattern）:將一個復雜對象的構建于它的表示分離，使得同樣的構建過程可以創建不同的表示。
建造者模式使得建造代碼與表示代碼的分離，可以使客戶端不必知道產品內部組成的細節，從而降低了客戶端與具體產品之間的耦合度，下面通過類圖來幫助大家更好地理清建造者模式中類之間的關系。
介紹完了建造者模式的具體實現之后，讓我們總結下建造模式的實現要點：
在建造者模式中，指揮者是直接與客戶端打交道的，指揮者將客戶端創建產品的請求劃分為對各個部件的建造請求，再將這些請求委派到具體建造者角色，具體建造者角色是完成具體產品的構建工作的，卻不為客戶所知道。
建造者模式主要用于“分步驟來構建一個復雜的對象”，其中“分步驟”是一個固定的組合過程，而復雜對象的各個部分是經常變化的（也就是說電腦的內部組件是經常變化的，這里指的的變化如硬盤的大小變了，CPU由單核變雙核等）。
產品不需要抽象類，由于建造模式的創建出來的最終產品可能差異很大，所以不大可能提煉出一個抽象產品類。
在前面文章中介紹的抽象工廠模式解決了“系列產品”的需求變化，而建造者模式解決的是 “產品部分” 的需要變化。
由于建造者隱藏了具體產品的組裝過程，所以要改變一個產品的內部表示，只需要再實現一個具體的建造者就可以了，從而能很好地應對產品組成組件的需求變化。
前面的設計模式在.NET類庫中都有相應的實現，那在.NET 類庫中，是否也存在建造者模式的實現呢？ 然而對于疑問的答案是肯定的，在.NET 類庫中，System.Text.StringBuilder(存在mscorlib.dll程序集中)就是一個建造者模式的實現。不過它的實現屬于建造者模式的演化，此時的建造者模式沒有指揮者角色和抽象建造者角色，StringBuilder類即扮演著具體建造者的角色，也同時扮演了指揮者和抽象建造者的角色，此時建造模式的實現如下：
/// <summary>
/// 建造者模式的演變
/// 省略了指揮者角色和抽象建造者角色
/// 此時具體建造者角色扮演了指揮者和建造者兩個角色
/// </summary>
public class Builder
{
// 具體建造者角色的代碼
private Product product = new Product();
public void BuildPartA()
{
product.Add("PartA");
}
public void BuildPartB()
{
product.Add("PartB");
}
public Product GetProduct()
{
return product;
}
// 指揮者角色的代碼
public void Construct()
{
BuildPartA();
BuildPartB();
}
}
/// <summary>
/// 產品類
/// </summary>
public class Product
{
// 產品組件集合
private IList<string> parts = new List<string>();
// 把單個組件添加到產品組件集合中
public void Add(string part)
{
parts.Add(part);
}
public void Show()
{
Console.WriteLine("產品開始在組裝.......");
foreach (string part in parts)
{
Console.WriteLine("組件" + part + "已裝好");
}
Console.WriteLine("產品組裝完成");
}
}
// 此時客戶端也要做相應調整
class Client
{
private static Builder builder;
static void Main(string[] args)
{
builder = new Builder();
builder.Construct();
Product product = builder.GetProduct();
product.Show();
Console.Read();
}
}StringBuilder類扮演著建造string對象的具體建造者角色，其中的ToString()方法用來返回具體產品給客戶端（相當于上面代碼中GetProduct方法）。其中Append方法用來創建產品的組件(相當于上面代碼中BuildPartA和BuildPartB方法)，因為string對象中每個組件都是字符，所以也就不需要指揮者的角色的代碼（指的是Construct方法,用來調用創建每個組件的方法來完成整個產品的組裝），因為string字符串對象中每個組件都是一樣的,都是字符,所以Append方法也充當了指揮者Construct方法的作用。
到這里,建造者模式的介紹就結束了,建造者模式(Builder Pattern)，將一個復雜對象的構建與它的表示分離，使的同樣的構建過程可以創建不同的表示。建造者模式的本質是使組裝過程（用指揮者類進行封裝，從而達到解耦的目的）和創建具體產品解耦,使我們不用去關心每個組件是如何組裝的。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
