Builder Pattern

4. 建造者模式

4.1. 模式動機

無論是在現實世界中還是在軟件系統中，都存在一些複雜的對象，它們擁有多個組成部分，如汽車，它包括車輪、方向盤、發送機等各種部件。而對於大多數用戶而言，無須知道這些部件的裝配細節，也幾乎不會使用單獨某個部件，而是使用一輛完整的汽車，可以通過建造者模式對其進行設計與描述，建造者模式可以將部件和其組裝過程分開，一步一步創建一個複雜的對象。用戶只需要指定複雜對象的類型就可以得到該對象，而無須知道其內部的具體構造細節。
在軟件開發中，也存在大量類似汽車一樣的複雜對象，它們擁有一系列成員屬性，這些成員屬性中有些是引用類型的成員對象。而且在這些複雜對像中，還可能存在一些限制條件，如某些屬性沒有賦值則復雜對像不能作為一個完整的產品使用；有些屬性的賦值必須按照某個順序，一個屬性沒有賦值之前，另一個屬性可能無法賦值等。
複雜對象相當於一輛有待建造的汽車，而對象的屬性相當於汽車的部件，建造產品的過程就相當於組合部件的過程。由於組合部件的過程很複雜，因此，這些部件的組合過程往往被“外部化”到一個稱作建造者的對象裡，建造者返還給客戶端的是一個已經建造完畢的完整產品對象，而用戶無須關心該對象所包含的屬性以及它們的組裝方式，這就是建造者模式的模式動機。

4.2. 模式定義

造者模式(Builder Pattern)：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
建造者模式是一步一步創建一個複雜的對象，它允許用戶只通過指定複雜對象的類型和內容就可以構建它們，用戶不需要知道內部的具體構建細節。建造者模式屬於對象創建型模式。根據中文翻譯的不同，建造者模式又可以稱為生成器模式。

4.3. 模式結構

建造者模式包含如下角色：
  • Builder：抽象建造者
  • ConcreteBuilder：具體建造者
  • Director：指揮者
  • Product：產品角色

4.4. 時序圖


4.5. 代碼分析

#include <iostream>
#include "ConcreteBuilder.h"
#include "Director.h"
#include "Builder.h"
#include "Product.h"

using namespace std ;

int main ( int argc , char * argv [])
{
ConcreteBuilder * builder = new ConcreteBuilder (); Director director ; director . setBuilder ( builder ); Product * pd = director . constuct (); pd -> show (); delete builder ; delete pd ; return 0 ; }

////////////////////////////////////////////////// /////////
// ConcreteBuilder.cpp
// Implementation of the Class ConcreteBuilder
// Created on: 02-十月-2014 15:57:03
// Original author: colin
/////// ////////////////////////////////////////////////// //

#include "ConcreteBuilder.h"

ConcreteBuilder :: ConcreteBuilder (){
}
ConcreteBuilder ::~ ConcreteBuilder (){

}

void ConcreteBuilder :: buildPartA (){
m_prod -> setA ( "A Style " ); //不同的建造者，可以實現不同產品的建造   } void ConcreteBuilder :: buildPartB (){ m_prod -> setB ( "B Style " ); } void ConcreteBuilder :: buildPartC (){ m_prod -> setC ( "C style " ); }

////////////////////////////////////////////////// /////////
// Director.cpp
// Implementation of the Class Director
// Created on: 02-十月-2014 15:57:01
// Original author: colin
/////// ////////////////////////////////////////////////// //

#include "Director.h"

Director :: Director (){
}
Director ::~ Director (){
}
Product * Director :: constuct (){
m_pbuilder -> buildPartA (); m_pbuilder -> buildPartB (); m_pbuilder -> buildPartC (); return m_pbuilder -> getResult (); }

void Director :: setBuilder ( Builder * buider ){
        m_pbuilder = buider ;
}

4.6. 模式分析

抽象建造者類中定義了產品的創建方法和返回方法;
建造者模式的結構中還引入了一個指揮者類Director，該類的作用主要有兩個：一方面它隔離了客戶與生產過程；另一方面它負責控制產品的生成過程。指揮者針對抽象建造者編程，客戶端只需要知道具體建造者的類型，即可通過指揮者類調用建造者的相關方法，返回一個完整的產品對象
在客戶端代碼中，無須關心產品對象的具體組裝過程，只需確定具體建造者的類型即可，建造者模式將復雜對象的構建與對象的表現分離開來，這樣使得同樣的構建過程可以創建出不同的表現。

4.7. 實例

實例：KFC套餐
建造者模式可以用於描述KFC如何創建套餐：套餐是一個複雜對象，它一般包含主食（如漢堡、雞肉捲等）和飲料（如果汁、 可樂等）等組成部分，不同的套餐有不同的組成部分，而KFC的服務員可以根據顧客的要求，一步一步裝配這些組成部分，構造一份完整的套餐，然後返回給顧客。


4.8. 優點

  • 在建造者模式中，客戶端不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象。
  • 每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，用戶使用不同的具體建造者即可得到不同的產品對象。
  • 可以更加精細地控制產品的創建過程。將復雜產品的創建步驟分解在不同的方法中，使得創建過程更加清晰，也更方便使用程序來控制創建過程。
  • 增加新的具體建造者無須修改原有類庫的代碼，指揮者類針對抽象建造者類編程，系統擴展方便，符合“開閉原則”。

4.9. 缺點

  • 建造者模式所創建的產品一般具有較多的共同點，其組成部分相似，如果產品之間的差異性很大，則不適合使用建造者模式，因此其使用範圍受到一定的限制。
  • 如果產品的內部變化複雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大。

4.10. 適用環境

在以下情況下可以使用建造者模式：
  • 需要生成的產品對像有複雜的內部結構，這些產品對象通常包含多個成員屬性。
  • 需要生成的產品對象的屬性相互依賴，需要指定其生成順序。
  • 對象的創建過程獨立於創建該對象的類。在建造者模式中引入了指揮者類，將創建過程封裝在指揮者類中，而不在建造者類中。
  • 隔離複雜對象的創建和使用，並使得相同的創建過程可以創建不同的產品。

4.11. 模式應用

在很多遊戲軟件中，地圖包括天空、地面、背景等組成部分，人物角色包括人體、服裝、裝備等組成部分，可以使用建造者模式對其進行設計，通過不同的具體建造者創建不同類型的地圖或人物。

4.12. 模式擴展

建造者模式的簡化:
  • 省略抽象建造者角色：如果系統中只需要一個具體建造者的話，可以省略掉抽象建造者。
  • 省略指揮者角色：在具體建造者只有一個的情況下，如果抽象建造者角色已經被省略掉，那麼還可以省略指揮者角色，讓
Builder角色扮演指揮者與建造者雙重角色。

建造者模式與抽象工廠模式的比較:
  • 與抽象工廠模式相比，建造者模式返回一個組裝好的完整產品，而抽象工廠模式返回一系列相關的產品，這些產品位於不同的產品等級結構，構成了一個產品族。
  • 在抽象工廠模式中，客戶端實例化工廠類，然後調用工廠方法獲取所需產品對象，而在建造者模式中，客戶端可以不直接調用建造者的相關方法，而是通過指揮者類來指導如何生成對象，包括對象的組裝過程和建造步驟，它側重於一步步構造一個複雜對象，返回一個完整的對象。
  • 如果將抽象工廠模式看成汽車配件生產工廠，生產一個產品族的產品，那麼建造者模式就是一個汽車組裝工廠，通過對部件的組裝可以返回一輛完整的汽車。

4.13. 總結

  • 建造者模式將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。建造者模式是一步一步創建一個複雜的對象，它允許用戶只通過指定複雜對象的類型和內容就可以構建它們，用戶不需要知道內部的具體構建細節。建造者模式屬於對象創建型模式。
  • 建造者模式包含如下四個角色：抽象建造者為創建一個產品對象的各個部件指定抽象接口；具體建造者實現了抽象建造者接口，實現各個部件的構造和裝配方法，定義並明確它所創建的複雜對象，也可以提供一個方法返回創建好的複雜產品對象；產品角色是被構建的複雜對象，包含多個組成部件；指揮者負責安排複雜對象的建造次序，指揮者與抽象建造者之間存在關聯關係，可以在其construct()建造方法中調用建造者對象的部件構造與裝配方法，完成複雜對象的建造
  • 在建造者模式的結構中引入了一個指揮者類，該類的作用主要有兩個：一方面它隔離了客戶與生產過程；另一方面它負責控制產品的生成過程。指揮者針對抽象建造者編程，客戶端只需要知道具體建造者的類型，即可通過指揮者類調用建造者的相關方法，返回一個完整的產品對象。
  • 建造者模式的主要優點在於客戶端不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象，每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，符合“開閉原則”，還可以更加精細地控制產品的創建過程；其主要缺點在於由於建造者模式所創建的產品一般具有較多的共同點，其組成部分相似，因此其使用範圍受到一定的限制，如果產品的內部變化複雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大。
  • 建造者模式適用情況包括：需要生成的產品對像有複雜的內部結構，這些產品對象通常包含多個成員屬性；需要生成的產品對象的屬性相互依賴，需要指定其生成順序；對象的創建過程獨立於創建該對象的類；隔離複雜對象的創建和使用，並使得相同的創建過程可以創建不同類型的產品。





留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容