大白話建造者模式(Builder Pattern)

前言

起初打算按照以前的日產系列寫建造者模式。但參考了網上的不少文章,讓我對建造者模式更加的困惑,也懼怕本身沒法已易懂的方式進行解釋。最後經過Google發現了一篇英文文章Builder,使我茅塞頓開。我本身對這篇文章進行了翻譯,但願對你們理解建造者模式有幫助。設計模式

意圖

建造者模式是建立型設計模式,用來逐步建立複雜的對象。使用建造者模式可使用相同的構造代碼生成不一樣類型、不一樣表示的對象。
數組

問題

想象一個複雜的對象,它須要大量字段和嵌套對象進行初始化。這種的初始化代碼通常會隱藏在一個包含大量參數的龐大構造函數中。
爲對象的每一種可能建立子類,會使程序過於複雜。函數

好比,咱們來建一個房子對象。建造一個簡單的房子須要四面牆、一層地板、一扇門、一對窗戶和一個屋頂。可是若是咱們想要一個更大更明亮,而且有後院和其餘好東西(好比暖氣系統、管道和電線)的房子,那該怎麼辦呢?ui

最簡單的解決方案是繼承基本House類並建立一組子類來覆蓋全部參數組合,可是後獲得大量的子類。任何新的參數都須要進一步擴展這個層次結構。翻譯

另外一個方法不用派生子類。你能夠建立一個包含全部參數的構造函數。這種方法不須要大量的子類,可是存在另外的問題。
大量參數的構造函數也存在問題,並不是全部參數都是被須要的
在大多數狀況下,大部分的參數是不被使用的。這樣調用構造函數時會顯得代碼十分難看。設計

解決

建造模式建議您從本身的類中提取對象構造代碼,將其移動到被稱爲生成器的獨立對象中。
建造者模式容許您逐步構造複雜的對象。構建器在構建產品時不容許其餘對象訪問該產品。對象

建造者模式將對象構造組織爲一組步驟(建牆、建門等)。在Builder對象上執行一系列步驟就能夠建立一個對象。最重要的一點是,您無需調用全部的步驟,須要調用須要的步驟便可。blog

當須要構建產品的各類表現形式時,某些步驟可能須要不一樣的實現。好比,小屋的牆壁能夠用木頭建造,但城堡的牆壁須要用石頭建造。
這種場景下,能夠建立不一樣的建造者類來實現相同的建造步驟,不一樣的類型。接下來就可使用這些建造不一樣類型的對象。繼承

不一樣的建造者以不一樣的方式執行相同的任務,生成不一樣的

例如,第一個建造者用木頭和玻璃建造一切,第二個用石頭和鐵建造一切,第三個用黃金和鑽石建造一切。經過調用相同的步驟,你能夠從第一個建造者那裏獲得一個普通的房子,從第二個建造者那裏獲得一個小城堡,從第三個建造者那裏獲得一個宮殿。接口

Director

咱們能夠進一步的將一系列對建造者步驟的調用提取到一個類中,這個類被稱爲Director。
Director類只定義了執行構建步驟的順序,而構建器提供了這些步驟的實現。
Director知道執行哪些構建步驟來得到產品
Direct類不是絕對必要的,咱們能夠按照特定的順序直接調用Builder。可是,Director是放置各類可重用構造方案的好方法。
另外,Director類徹底隱藏了產品構造的細節。客戶端只須要將一個Builder和一個Director關聯起來就能夠獲得構建結果。

結構

  1. Builder接口聲明瞭對全部類型的生成器都通用的產品構造步驟。
  2. Concrete Builders 提供了
    構建步驟的不一樣實現。
  3. Products是須要產生的對象。不一樣構造器構建的產品能夠屬於不一樣的類層級結構(繼承)或者接口。
  4. Director類定義了調用構造步驟的順序,所以您能夠建立和重用產品的特定構造方式。
  5. Client必須將一個Builder對象與Director關聯起來。一般,經過director的構造函數的參數只執行一次。而後,director將該Builder對象用於全部的構造。還有一種方式是將Builder對象傳遞給Director的方法,可使用不一樣的生成器。

場景

  • 建造者模式用來拜託過長的構造函數。
  • 建立某些產品的不一樣表示形式,好比石房和木房。
  • 構造複雜對象,將構造代碼和業務代碼分離。

    代碼

代碼我沒有粘過來,直接訪問參考文獻裏的底部便可。

參考文獻

https://refactoring.guru/design-patterns/builder

相關文章
相關標籤/搜索