引言
在軟體測試中,一個項目的自動化測試包括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 自動化測試執行完畢!
============ 執行測試用例結束 ============
适用場景
- 當建立複雜對象的算法應該獨立于該對象的組成部分以及它們的裝配方式時。
- 相同的方法,不同的執行順序,産生不同的事件結果時。
- 多個部件或零件,都可以裝配到一個對象中,但是産生的運作結果又不相同時。
- 産品類非常複雜,或者産品類中的調用順序不同産生了不同的效能。
- 建立一些複雜的對象時,這些對象的内部組成構件間的建造順序是穩定的,但是對象的内部組成構件面臨着複雜的變化。
優缺點
優點:
- 封裝性好,建構和表示分離。
- 擴充性好,各個具體的建造者互相獨立,有利于系統的解耦。
- 用戶端不必知道産品内部組成的細節,建造者可以對建立過程逐漸細化,而不對其它子產品産生任何影響,便于控制細節風險。
缺點:
- 産品的組成部分必須相同,這限制了其使用範圍。
- 如果産品的内部變化複雜,如果産品内部發生變化,則建造者也要同步修改,後期維護成本較大。
與工廠模式差別
- 建造者模式更加注重方法的調用順序,工廠模式注重建立對象。
- 建立對象的力度不同,建造者模式建立複雜的對象,由各種複雜的部件組成,工廠模式建立出來的對象都一樣
- 關注重點不一樣,工廠模式隻需要把對象建立出來就可以了,而建造者模式不僅要建立出對象,還要知道對象由哪些部件組成。
- 建造者模式根據建造過程中的順序不一樣,最終對象部件組成也不一樣。