C#設計模式-建造者模式（Builder Pattern）
阿新 • • 發佈：2020-11-13
引言
在軟體測試中，一個專案的自動化測試包括UI自動化、API自動化、壓力自動化等，把這些不同型別的自動化測試組裝在一起變構成了一個專案的自動化測試。通過執行專案的自動化測試變能執行他的所有型別的自動化測試。當然，在生活中也有類似的，比如電腦，由CPU、磁碟、顯示卡等部分組成，一輛車由輪胎、車體、發動機等部件構成，客戶在買車的時候並不知道該車是如何組裝的，他只需要會開這輛車就行了。在設計模式中，我們將類似的複雜物件的各個部分按照一定的演算法組合在一起，這種物件的建立工作便稱為建造者模式。
簡介
定義
建造者模式（Builder Pattern）使用多個簡單的物件一步一步構建成一個複雜的物件，將複雜的構建與其表示相分離，使得同樣的構建過程可以建立不同的表示。這種型別的設計模式屬於建立型模式，它提供了一種建立物件的最佳方式。
主要解決的問題
在軟體系統中，有時候面臨一個"複雜物件"的建立工作，其通常由各個部分的子物件用一定演算法構成;由於需求的變化，這個複雜物件的各個部分經常面臨著劇烈的變化，但是將它們組合到一起的演算法卻相對穩定。如何應對這種變化？如何提供一種“封裝機制”來隔離出“複雜物件的各個部分”的變化，從而保持系統中的“穩定構建演算法”不隨著需求改變而改變？
將一個複雜物件的構建與其表示相分離，使得同樣的構建過程可以建立不同的表示。 變與不變分離開。
結構圖
主要角色
-
抽象建造者角色（Builder）：為建立一個Product物件的各個部件指定抽象介面，以規範產品物件的各個組成成分的建造。一般而言，此角色規定要實現複雜物件的哪些部分的建立，並不涉及具體的物件部件的建立。
-
具體建造者（ConcreteBuilder）
-
實現Builder的介面以構造和裝配該產品的各個部件。即實現抽象建造者角色Builder的方法。
-
定義並明確它所建立的表示，即針對不同的商業邏輯，具體化複雜物件的各部分的建立。
-
提供一個檢索產品的介面。
-
構造一個使用Builder介面的物件即在指導者的呼叫下建立產品例項。
-
-
指導者（Director）：呼叫具體建造者角色以建立產品物件的各個部分。指導者並沒有涉及具體產品類的資訊，真正擁有具體產品的資訊是具體建造者物件。它只負責保證物件各部分完整建立或按某種順序建立。
-
產品角色（Product）：建造中的複雜物件。它要包含那些定義元件的類，包括將這些元件裝配成產品的介面。
具體實現
以一個專案的自動化測試由UI自動化、API自動化、壓力自動化組成為例。
產品角色。自動化測試類。
public sealed class AuToTest
{
// 測試用例收集
private IList<string> allCases = new List<string>();
// 將所有的測試用例集中在一起
public void addCases(string testcases)
{
allCases.Add(testcases);
}
// 進行測試
public void Test()
{
Console.WriteLine("============ 開始執行測試用例 ============");
foreach (string cases in allCases)
{
Console.WriteLine(cases + "執行完畢！");
}
Console.WriteLine("============ 執行測試用例結束 ============");
}
}
抽象建造者：包含建立產品各個子部件的抽象方法。自動化測試類。
public abstract class Builder
{
// 建立UI自動化測試用例
public abstract void BuildCasesUI();
// 建立介面自動化測試用例
public abstract void BuildCasesAPI();
// 建立效能自動化測試
public abstract void BuildCasesStress();
// 獲得組裝好的
public abstract AuToTest GetAuToTest();
}
具體建造者：實現了抽象建造者介面。以百度自動化測試和華為自動化測試為例。
public class BaiduBuidler : Builder
{
AuToTest BaiduAutoTest = new AuToTest();
public override void BuildCasesUI()
{
BaiduAutoTest.addCases("百度 UI 自動化測試");
}
public override void BuildCasesAPI()
{
BaiduAutoTest.addCases("百度 API 自動化測試");
}
public override void BuildCasesStress()
{
BaiduAutoTest.addCases("百度 Stress 自動化測試");
}
public override AuToTest GetAuToTest()
{
return BaiduAutoTest;
}
}
/// 具體建立者，比如華為
public class HuaWeiBuidler : Builder
{
AuToTest HuaWeiAutoTest = new AuToTest();
public override void BuildCasesUI()
{
HuaWeiAutoTest.addCases("華為 UI 自動化測試");
}
public override void BuildCasesAPI()
{
HuaWeiAutoTest.addCases("華為 API 自動化測試");
}
public override void BuildCasesStress()
{
HuaWeiAutoTest.addCases("華為 Stress 自動化測試");
}
public override AuToTest GetAuToTest()
{
return HuaWeiAutoTest;
}
}
指揮者：呼叫建造者中的方法完成複雜物件的建立。將UI自動化、API自動化、壓力自動化組建成專案自動化測試。
public class Director
{
// 所有自動化測試組裝成一個專案的自動化
public void Construct(Builder builder)
{
builder.BuildCasesUI();
builder.BuildCasesAPI();
builder.BuildCasesStress();
}
}
客戶類。
class Customer
{
static void Main(string[] args)
{
Director director = new Director();
Builder baiduBuilder = new BaiduBuidler();
Builder huaweiBuidler = new HuaWeiBuidler();
// 百度專案進行組裝
director.Construct(baiduBuilder);
// 組裝完成後進行執行專案的自動化測試
AuToTest baiduAutoTest = baiduBuilder.GetAuToTest();
baiduAutoTest.Test();
// 華為專案進行自動化測試
director.Construct(huaweiBuidler);
AuToTest huaweiAutoTest = huaweiBuidler.GetAuToTest();
huaweiAutoTest.Test();
}
}
完整程式碼
using System;
using System.Collections.Generic;
namespace 建造者模式
{
/// <summary>
/// 客戶端
/// </summary>
class Customer
{
static void Main(string[] args)
{
Director director = new Director();
Builder baiduBuilder = new BaiduBuidler();
Builder huaweiBuidler = new HuaWeiBuidler();
// 百度專案進行組裝
director.Construct(baiduBuilder);
// 組裝完成後進行執行專案的自動化測試
AuToTest baiduAutoTest = baiduBuilder.GetAuToTest();
baiduAutoTest.Test();
// 華為專案進行自動化測試
director.Construct(huaweiBuidler);
AuToTest huaweiAutoTest = huaweiBuidler.GetAuToTest();
huaweiAutoTest.Test();
}
}
/// <summary>
/// 建造者模式中的指揮者
/// 不同型別的組裝，Construct 方法裡面的實現就是建立複雜物件固定演算法的實現，是相對穩定的
/// </summary>
public class Director
{
// 所有自動化測試組裝成一個專案的自動化
public void Construct(Builder builder)
{
builder.BuildCasesUI();
builder.BuildCasesAPI();
builder.BuildCasesStress();
}
}
/// <summary>
/// 自動化測試類
/// </summary>
public sealed class AuToTest
{
// 測試用例收集
private IList<string> allCases = new List<string>();
// 將所有的測試用例集中在一起
public void addCases(string testcases)
{
allCases.Add(testcases);
}
// 進行測試
public void Test()
{
Console.WriteLine("============ 開始執行測試用例 ============");
foreach (string cases in allCases)
{
Console.WriteLine(cases + "執行完畢！");
}
Console.WriteLine("============ 執行測試用例結束 ============");
}
}
/// <summary>
/// 抽象建造者，定義自動化測試時需要那些內容，和最後建立的結果
/// 在這兒要和組裝進行區分，這不是組裝的型別
/// </summary>
public abstract class Builder
{
// 建立UI自動化測試用例
public abstract void BuildCasesUI();
// 建立介面自動化測試用例
public abstract void BuildCasesAPI();
// 建立效能自動化測試
public abstract void BuildCasesStress();
// 獲得組裝好的
public abstract AuToTest GetAuToTest();
}
/// <summary>
/// 具體建立者，就是什麼專案進行自動化測試，比如百度
/// </summary>
public class BaiduBuidler : Builder
{
AuToTest BaiduAutoTest = new AuToTest();
public override void BuildCasesUI()
{
BaiduAutoTest.addCases("百度 UI 自動化測試");
}
public override void BuildCasesAPI()
{
BaiduAutoTest.addCases("百度 API 自動化測試");
}
public override void BuildCasesStress()
{
BaiduAutoTest.addCases("百度 Stress 自動化測試");
}
public override AuToTest GetAuToTest()
{
return BaiduAutoTest;
}
}
/// <summary>
/// 具體建立者，就是什麼專案進行自動化測試，比如華為
/// </summary>
public class HuaWeiBuidler : Builder
{
AuToTest HuaWeiAutoTest = new AuToTest();
public override void BuildCasesUI()
{
HuaWeiAutoTest.addCases("華為 UI 自動化測試");
}
public override void BuildCasesAPI()
{
HuaWeiAutoTest.addCases("華為 API 自動化測試");
}
public override void BuildCasesStress()
{
HuaWeiAutoTest.addCases("華為 Stress 自動化測試");
}
public override AuToTest GetAuToTest()
{
return HuaWeiAutoTest;
}
}
}
執行結果
============ 開始執行測試用例 ============ 百度 UI 自動化測試執行完畢！ 百度 API 自動化測試執行完畢！ 百度 Stress 自動化測試執行完畢！ ============ 執行測試用例結束 ============ ============ 開始執行測試用例 ============ 華為 UI 自動化測試執行完畢！ 華為 API 自動化測試執行完畢！ 華為 Stress 自動化測試執行完畢！ ============ 執行測試用例結束 ============
適用場景
- 當建立複雜物件的演算法應該獨立於該物件的組成部分以及它們的裝配方式時。
- 相同的方法，不同的執行順序，產生不同的事件結果時。
- 多個部件或零件,都可以裝配到一個物件中，但是產生的執行結果又不相同時。
- 產品類非常複雜，或者產品類中的呼叫順序不同產生了不同的效能。
- 建立一些複雜的物件時，這些物件的內部組成構件間的建造順序是穩定的，但是物件的內部組成構件面臨著複雜的變化。
優缺點
優點：
- 封裝性好，構建和表示分離。
- 擴充套件性好，各個具體的建造者相互獨立，有利於系統的解耦。
- 客戶端不必知道產品內部組成的細節，建造者可以對建立過程逐步細化，而不對其它模組產生任何影響，便於控制細節風險。
缺點：
- 產品的組成部分必須相同，這限制了其使用範圍。
- 如果產品的內部變化複雜，如果產品內部發生變化，則建造者也要同步修改，後期維護成本較大。
與工廠模式區別
- 建造者模式更加註重方法的呼叫順序，工廠模式注重建立物件。
- 建立物件的力度不同，建造者模式建立複雜的物件，由各種複雜的部件組成，工廠模式創建出來的物件都一樣
- 關注重點不一樣，工廠模式只需要把物件創建出來就可以了，而建造者模式不僅要創建出物件，還要知道物件由哪些部件組成。
- 建造者模式根據建造過程中的順序不一樣，最終物件部件組成也不一樣。