home > theory > model >

再談設計模式—模式23種設計模式總結

author:[email protected]    hits:

軟件設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。設計模式的本質是面向對象設計原則的實際運用,是對類的封裝性、繼承性和多態性以及類的關聯關系和組合關系的充分理解。

這篇文章是對設計模式的再談系列總結性筆記,推薦閱讀C語言中文網上的《軟件設計模式概述

什么是設計模式

軟件設計模式(Software Design Pattern)是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結

它描述了在軟件設計過程中的一些不斷重復發生的問題,以及該問題的解決方案。也就是說,它是解決特定問題的一系列套路,是前輩們的代碼設計經驗的總結,具有一定的普遍性,可以反復使用。其目的是為了提高代碼的可重用性、代碼的可讀性和代碼的可靠性

設計模式的本質是面向對象設計原則的實際運用,是對類的封裝性、繼承性和多態性以及類的關聯關系和組合關系的充分理解。正確使用設計模式具有以下優點:

  • 可以提高程序員的思維能力、編程能力和設計能力。

  • 使程序設計更加標準化、代碼編制更加工程化,使軟件開發效率大大提高,從而縮短軟件的開發周期。

  • 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。

設計模式有兩種分類方法,即根據模式的目的來分和根據模式的作用的范圍來分。

設計模式的分類

根據目的來分:即根據模式是用來完成什么工作來劃分,這種方式可分為創建型模式、結構型模式和行為型模式 3 種。

  • 創建型模式:對象實例化的模式,創建型模式用于解耦對象的實例化過程。描述“怎樣創建對象”,它的主要特點是“將對象的創建與使用分離”

    共五種:單例模式、原型模式、工廠方法模式、抽象工廠模式、建造者模式。唯有工廠方法模式屬于類創建型模式

  • 結構型模式:把類或對象結合在一起形成一個更大的結構。用于描述如何將類或對象按某種布局組成更大的結構

    共七種:適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

  • 行為型模式:類和對象如何交互,及劃分責任和算法。描述類或對象之間怎樣相互協作共同完成單個對象都無法單獨完成的任務,以及怎樣分配職責。

    共十一種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

根據作用范圍來分:即根據模式是主要用于類上還是主要用于對象上來分,這種方式可分為類模式和對象模式兩種。

  • 類模式:用于處理類與子類之間的關系,這些關系通過繼承來建立,是靜態的,在編譯時刻便確定下來了。

    共四種:工廠方法、(類)適配器、模板方法、解釋器。

  • 對象模式:用于處理對象之間的關系,這些關系可以通過組合或聚合來實現,在運行時刻是可以變化的,更具動態性。

    GoF 中除了以上 4 種,其他的都是對象模式。

23 種設計模式的分類表

范圍\目的創建型模式結構型模式行為型模式
類模式工廠方法(類)適配器模板方法、解釋器
對象模式單例
原型
抽象工廠
建造者
代理
(對象)適配器
橋接
裝飾
外觀
享元
組合
策略
命令
職責鏈
狀態
觀察者
中介者
迭代器
訪問者
備忘錄

GoF的23種軟件設計模式列表

  • 單例模式(Singleton pattern):某個類只能有一個實例,提供一個全局的訪問點。

  • 工廠方法(factory method pattern):定義一個創建對象的接口,讓子類決定實例化那個類。

  • 抽象工廠(Abstract factory pattern):創建相關或依賴對象的家族,而無需明確指定具體類。

  • 建造者模式(Builder pattern):封裝一個復雜對象的構建過程,并可以按步驟構造。

  • 原型模式(prototype pattern):通過復制現有的實例來創建新的實例。


  • 適配器模式(Adapter pattern):將一個類的方法接口轉換成客戶希望的另外一個接口。

  • 組合模式(composite pattern):將對象組合成樹形結構以表示“”部分-整體“”的層次結構。

  • 裝飾模式(decorator pattern):動態的給對象添加新的功能。

  • 代理模式(Proxy pattern):為其他對象提供一個代理以便控制這個對象的訪問。

  • 亨元(蠅量)模式(Flyweight Pattern):通過共享技術來有效的支持大量細粒度的對象。

  • 外觀模式(facade pattern):對外提供一個統一的方法,來訪問子系統中的一群接口。

  • 橋接模式(Bridge pattern):將抽象部分和它的實現部分分離,使它們都可以獨立的變化。


  • 模板模式(Template pattern):定義一個算法結構,而將一些步驟延遲到子類實現。

  • 解釋器模式(Interpreter pattern):給定一個語言,定義它的文法的一種表示,并定義一個解釋器。

  • 策略模式(strategy pattern):定義一系列算法,把他們封裝起來,并且使它們可以相互替換。

  • 狀態模式(State pattern):允許一個對象在其對象內部狀態改變時改變它的行為。

  • 觀察者模式(observer pattern):對象間的一對多的依賴關系。

  • 備忘錄模式(Memento pattern):在不破壞封裝的前提下,保持對象的內部狀態。

  • 中介者模式(Mediator pattern):用一個中介對象來封裝一系列的對象交互。

  • 命令模式(Command pattern):將命令請求封裝為一個對象,使得可以用不同的請求來進行參數化。

  • 訪問者模式(visitor pattern):在不改變數據結構的前提下,增加作用于一組對象元素的新功能。

  • 責任鏈模式(Chain of responsibility pattern):將請求的發送者和接收者解耦,使的多個對象都有處理這個請求的機會。

  • 迭代器模式(iterator pattern):一種遍歷訪問聚合對象中各個元素的方法,不暴露該對象的內部結構。

其實還有兩類:并發型模式線程池模式



概說24種設計模式

在程序開發中,有些對象我們只需要一個,比如說:線程池、對話框、緩存、唯一的序列號生成器、有狀態的工具類對象等。如果我們實例化多個對象就可能會出錯。那么怎樣才能保證一個類只有一個實例化對象呢?

這里我們想到了全局變量,全局變量確實是可以。保證該類可以隨時訪問,但是它很難解決只有一個實例問題。

最好的辦法就是讓該自身來負責保存它的唯一實例。這個類必須要保證沒有其他類來創建它。這里我們可以將其構造方法私有化。

單例模式(Singleton pattern)   

確保某一個類只有一個實例,并且提供一個全局訪問點。就是保證一個類僅有一個實例即可「new 一次」

單例模式具備典型的3個特點:1、只有一個實例。 2、自我實例化。 3、提供全局訪問點

因此當系統中只需要一個實例對象或者系統中只允許一個公共訪問點,除了這個公共訪問點外,不能通過其他訪問點訪問該實例時,可以使用單例模式

單例模式的優缺點:

單例模式的主要優點就是節約系統資源、提高了系統效率,同時也能夠嚴格控制客戶對它的訪問。也許就是因為系統中只有一個實例,這樣就導致了單例類的職責過重,違背了“單一職責原則”,同時也沒有抽象類,所以擴展起來有一定的困難

Gson、Retrofit對象,ServiceManager等,Android系統提供的各種XXXManager(NotificationManager)等等,這些通過單例的方式去管理它,能夠讓你業務設計的更加嚴謹

單例模式的優點 

    1.在單例模式中,活動的單例只有一個實例,對單例類的所有實例化得到的都是相同的一個實例。這樣就 防止其它對象對自己的實例化,確保所有的對象都訪問一個實例 

    2.單例模式具有一定的伸縮性,類自己來控制實例化進程,類就在改變實例化進程上有相應的伸縮性。 

    3.提供了對唯一實例的受控訪問。 

    4.由于在系統內存中只存在一個對象,因此可以 節約系統資源,當需要頻繁創建和銷毀的對象時單例模式無疑可以提高系統的性能。 

    5.允許可變數目的實例。 

    6.避免對共享資源的多重占用。 

單例模式的缺點: 

    1.不適用于變化的對象,如果同一類型的對象總是要在不同的用例場景發生變化,單例就會引起數據的錯誤,不能保存彼此的狀態。 

    2.由于單利模式中沒有抽象層,因此單例類的擴展有很大的困難。 

    3.單例類的職責過重,在一定程度上違背了“單一職責原則”。 

    4.濫用單例將帶來一些負面問題,如為了節省資源將數據庫連接池對象設計為的單例類,可能會導致共享連接池對象的程序過多而出現連接池溢出;如果實例化的對象長時間不被利用,系統會認為是垃圾而被回收,這將導致對象狀態的丟失。 

使用注意事項: 

    1.使用時不能用反射模式創建單例,否則會實例化一個新的對象 

    2.使用懶單例模式時注意線程安全問題 

    3.單例模式和懶單例模式構造方法都是私有的,因而是不能被繼承的,有些單例模式可以被繼承(如登記式模式) 

單例模式的模式實現

由類是否在被加載時就將自己實例化,可以將單例模式分為兩種:

餓漢式

在被引用的時候就被實例化。類一旦加載就創建一個單例,保證在調用 getInstance 方法之前單例已經存在了,「把這一過程當作一個漢堡,也就是說必須要把漢堡提前準備好,餓貨就知道吃」

餓漢式特點:是線程安全的,類不是延時加載「直接是類加載的時候就初始化」

  • 餓漢式優點:沒有加鎖,執行效率非常高「其實是以空間來換時間」

  • 餓漢式缺點:在類加載的時候就會初始化,浪費內存「你知道我要不要使用這個實例嗎,你就給我初始化,太任性了」

懶漢式

在需要的時候才被實例化。類加載時沒有生成單例,只有當第一次調用 getlnstance 方法時才去創建這個單例

懶漢模式特點:線程不安全,延時初始化類,在我需要的時候「也就調用 getInstance」的時候才去初始化

  • 懶漢式優點:延時初始化類,省資源,不想用的時候就不會浪費內存

  • 懶漢式缺點線程不安全,多線程操作就會有問題;加鎖雖然線程安全,但對性能影響非常大「相當于排隊獲取資源,沒有拿到鎖子就干等」,雙重加鎖(雙重檢查鎖:double-checked locking)多線程仿問性能達到提升,但是雙檢鎖會遇到指令重排的問題,導致多線程下失效

推進閱讀《人人都會設計模式--單例模式--Singleton

js代碼實現:

 class Single {
  getSingle(fn) {
    var result;
    //由于閉包,所以當single.getSingle函數執行完之后,內存中并不會銷毀result。
    return function() {
      //單例模式的主要思想就是,實例如果已經創建,則直接返回
      return result || (result = fn.apply(this, arguments))
    }
  }
}

java代碼實現

public class SingletonTest {  
    private static SingletonTest instance = null;  
    private Vector properties = null;  
  
    public Vector getProperties() {  
        return properties;  
    }  
  
    private SingletonTest() {  }  
  
    private static synchronized void syncInit() {  
        if (instance == null) {  
            instance = new SingletonTest();  
        }  
    }  
  
    public static SingletonTest getInstance() {  
        if (instance == null) {  
            syncInit();  
        }  
        return instance;  
    }  
  
    public void updateProperties() {  
        SingletonTest shadow = new SingletonTest();  
        properties = shadow.getProperties();  
    }  
}
單例模式的應用場景
  • 在應用場景中,某類只要求生成一個對象的時候,如一個班中的班長、每個人的身份證號等。

  • 當對象需要被共享的場合。由于單例模式只允許創建一個對象,共享該對象可以節省內存,并加快對象訪問速度。如 Web 中的配置對象、數據庫的連接池等。

  • 當某類需要頻繁實例化,而創建的對象又頻繁被銷毀的時候,如多線程的線程池、網絡連接池等。

原型模式

用一個已經創建的實例作為原型,通過復制該原型對象來創建一個和原型相同或相似的新對象。在這里,原型實例指定了要創建的對象的種類。用這種方式創建對象非常高效,根本無須知道對象創建的細節。例如,JavaScript就是基于原型模式,由于 Java 提供了對象的 clone() 方法,所以用 Java 實現原型模式很簡單。

原型模式的結構

原型模式包含以下主要角色。

  • 抽象原型類:規定了具體原型對象必須實現的接口。

  • 具體原型類:實現抽象原型類的 clone() 方法,它是可被復制的對象。

  • 訪問類:使用具體原型類中的 clone() 方法來復制新的對象。

模式的實現

原型模式的克隆分為淺克隆和深克隆,Java 中的 Object 類提供了淺克隆的 clone() 方法,具體原型類只要實現 Cloneable 接口就可實現對象的淺克隆

//具體原型類
class Realizetype implements Cloneable
{
    Realizetype()
    {
        System.out.println("具體原型創建成功!");
    }
    public Object clone() throws CloneNotSupportedException
    {
        System.out.println("具體原型復制成功!");
        return (Realizetype)super.clone();
    }
}
//原型模式的測試類
public class PrototypeTest
{
    public static void main(String[] args)throws CloneNotSupportedException
    {
        Realizetype obj1=new Realizetype();
        Realizetype obj2=(Realizetype)obj1.clone();
        System.out.println("obj1==obj2?"+(obj1==obj2));
    }
}

帶原型管理器的原型模式的結構圖

對象深、淺復制的概念:

  • 淺復制:將一個對象復制后,基本數據類型的變量都會重新創建,而引用類型,指向的還是原對象所指向的。

  • 深復制:將一個對象復制后,不論是基本數據類型還有引用類型,都是重新創建的。簡單來說,就是深復制進行了完全徹底的復制,而淺復制不徹底。

public class Prototype implements Cloneable, Serializable {  
  
    private static final long serialVersionUID = 1L;  
    private String string;  
  
    private SerializableObject obj;  
  
    /* 淺復制 */  
    public Object clone() throws CloneNotSupportedException {  
        Prototype proto = (Prototype) super.clone();  
        return proto;  
    }  
  
    /* 深復制 */  
    public Object deepClone() throws IOException, ClassNotFoundException {  
  
        /* 寫入當前對象的二進制流 */  
        ByteArrayOutputStream bos = new ByteArrayOutputStream();  
        ObjectOutputStream oos = new ObjectOutputStream(bos);  
        oos.writeObject(this);  
  
        /* 讀出二進制流產生的新對象 */  
        ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());  
        ObjectInputStream ois = new ObjectInputStream(bis);  
        return ois.readObject();  
    }  
  
    public String getString() {  
        return string;  
    }  
  
    public void setString(String string) {  
        this.string = string;  
    }  
  
    public SerializableObject getObj() {  
        return obj;  
    }  
  
    public void setObj(SerializableObject obj) {  
        this.obj = obj;  
    }  
  
}  
  
class SerializableObject implements Serializable {  
    private static final long serialVersionUID = 1L;  
}

要實現深復制,需要采用流的形式讀入當前對象的二進制輸入,再寫出二進制數據對應的對象。

工廠設計模式

我們把被創建的對象稱為“產品”,把創建產品的對象稱為“工廠”。如果要創建的產品不多,只要一個工廠類就可以完成,這種模式叫“簡單工廠模式”,它不屬于 GoF 的 23 種經典設計模式,它的缺點是增加新產品時會違背“開閉原則”

麥當勞和肯德基就是生產雞翅的Factory 工廠模式:客戶類和工廠類分開。消費者任何時候需要某種產品,只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時,工廠類也要做相應的修改。如:如何創建及如何向客戶端提供。

簡單工廠一般分為:

  • 普通簡單工廠:就是建立一個工廠類,對實現了同一接口的一些類進行實例的創建

  • 多方法簡單工廠:提供多個工廠方法,分別創建對象

  • 靜態方法簡單工廠:將上面的多個工廠方法模式里的方法置為靜態的,不需要創建實例,直接調用即可

工廠模式適合:凡是出現了大量的產品需要創建,并且具有共同的接口時,可以通過工廠方法模式進行創建。我們會選用靜態工廠方法模式——不需要實例化工廠類。

工廠模式簡而言之,就是要替代掉“new操作符”!

為什么需要替代new操作符?

因為有時候創建實例時需要大量的準備工作,而將這些準備工作全部放在構造函數中是非常危險的行為,有必要將創建實例的邏輯和使用實例的邏輯分開,方便以后擴展。


工廠模式js實現:

class Creator {
    create(name) {
        return new Animal(name)
    }
}
class Animal {
    constructor(name) {
        this.name = name
    }
}

var creator = new Creator()
var duck = creator.create('Duck');console.log(duck.name) // Duck
var chicken = creator.create('Chicken');console.log(chicken.name) // Chicken

一個工程模式優化例子

class People {
  constructor(des) {
    // 出現異步不能使用async await    // 函數調用時可能還未完成初始化    get('someUrl').then(data => {
      this.name = data.name
      get('someUrl?name=' + this.name).then(data => {
        this.age = data.age
      })
    })
    // 非成員函數耦合性變大    this.des = handleDes(des)
  }}

工產模式

// 還真別說,形式上好看的代碼,質量一般都比較高class People {
  name: string = ''
  age: number = 0
  des: string = ''
  constructor(name: string, age: number, des: string) {
    this.name = name
    this.age = age
    this.des = des
  }}async function peopleFactory(description:any){
  const name = await get('someUrl')
  const age = await get('someUrl?name='+name)
  const des = handle(description)
  return new People(name,age,des)}

工廠方法模式的主要優點有:

  • 用戶只需要知道具體工廠的名稱就可得到所要的產品,無須知道產品的具體創建過程;

  • 在系統增加新的產品時只需要添加具體產品類和對應的具體工廠類,無須對原工廠進行任何修改,滿足開閉原則;、

工廠方法模式缺點是:每增加一個產品就要增加一個具體產品類和一個對應的具體工廠類,這增加了系統的復雜度。

工廠方法模式(Factory Method)

簡單工廠模式有一個問題就是,類的創建依賴工廠類,也就是說,如果想要拓展程序,必須對工廠類進行修改,這違背了開閉原則,所以,從設計角度考慮,有一定的問題,如何解決?就用到工廠方法模式:

創建一個工廠接口和創建多個工廠實現類,這樣一旦需要增加新的功能,直接增加新的工廠類就可以了,不需要修改之前的代碼。

工廠方法模式:核心工廠類不再負責所有產品的創建,而是將具體創建的工作交給子類去做,成為一個抽象工廠角色,僅負責給出具體工廠類必須實現的接口,而不接觸哪一個產品類應當被實例化這種細節

請MM去麥當勞吃漢堡,不同的MM有不同的口味,要每個都記住是一件煩人的事情,我一般采用Factory Method模式,帶著MM到服務員那兒,說“要一個漢堡”,具體要什么樣的漢堡呢,讓MM直接跟服務員說就行了。 

實現方式:

a)     抽象產品類(也可以是接口)

b)     多個具體的產品類

c)     工廠類(包括創建a的實例的方法)

抽象工廠(Abstract factory pattern)

抽象工廠模式是工廠方法模式的升級版本,工廠方法模式只生產一個等級的產品,而抽象工廠模式可生產多個等級的產品。

  • 系統中有多個產品族,每個具體工廠創建同一族但屬于不同等級結構的產品。

  • 系統一次只可能消費其中某一族產品,即同族的產品一起使用。


電器工廠的產品等級與產品族

抽象工廠模式的結構

抽象工廠模式同工廠方法模式一樣,也是由抽象工廠、具體工廠、抽象產品和具體產品等 4 個要素構成,但抽象工廠中方法個數不同,抽象產品的個數也不同。

抽象工廠模式的主要角色如下。

  • 抽象工廠(Abstract Factory):提供了創建產品的接口,它包含多個創建產品的方法 newProduct(),可以創建多個不同等級的產品。

  • 具體工廠(Concrete Factory):主要是實現抽象工廠中的多個抽象方法,完成具體產品的創建。

  • 抽象產品(Product):定義了產品的規范,描述了產品的主要特性和功能,抽象工廠模式有多個抽象產品。

  • 具體產品(ConcreteProduct):實現了抽象產品角色所定義的接口,由具體工廠來創建,它 同具體工廠之間是多對一的關系。

抽象工廠模式的結構圖


工廠方法模式和抽象工廠模式不好分清楚,他們的區別如下:

工廠方法模式:

  • 一個抽象產品類,可以派生出多個具體產品類。   

  • 一個抽象工廠類,可以派生出多個具體工廠類。   

  • 每個具體工廠類只能創建一個具體產品類的實例。

抽象工廠模式:

  • 多個抽象產品類,每個抽象產品類可以派生出多個具體產品類。   

  • 一個抽象工廠類,可以派生出多個具體工廠類。   

  • 每個具體工廠類可以創建多個具體產品類的實例,也就是創建的是一個產品線下的多個產品。   

工廠方法模式和抽象工廠模的區別:

  • 工廠方法模式只有一個抽象產品類,而抽象工廠模式有多個。   

  • 工廠方法模式的具體工廠類只能創建一個具體產品類的實例,而抽象工廠模式可以創建多個。

  • 工廠方法創建 "一種" 產品,他的著重點在于"怎么創建",也就是說如果你開發,你的大量代碼很可能圍繞著這種產品的構造,初始化這些細節上面。也因為如此,類似的產品之間有很多可以復用的特征,所以會和模版方法相隨。 

  • 抽象工廠需要創建一些列產品,著重點在于"創建哪些"產品上,也就是說,如果你開發,你的主要任務是劃分不同差異的產品線,并且盡量保持每條產品線接口一致,從而可以從同一個抽象工廠繼承。

建造者模式

建造者模式將一個復雜對象的構建與表示分離,使得同樣的構建過程可以創建不同的表示。

如果我們用了建造者模式,那么用戶就只需要指定需要建造的類型就可以得到他們,而具體的過程以及細節就不需要知道

例如,計算機是由 OPU、主板、內存、硬盤、顯卡、機箱、顯示器、鍵盤、鼠標等部件組裝而成的,采購員不可能自己去組裝計算機,而是將計算機的配置要求告訴計算機銷售公司,計算機銷售公司安排技術人員去組裝計算機,然后再交給要買計算機的采購員。

建造者返回給客戶一個完整的的產品對象,而客戶端無須關心該對象所包含的額屬性和組建方式,這就是建造者模式的設計動機

建造者模式的結構

建造者(Builder)模式的主要角色如下。

  1. 產品角色(Product):它是包含多個組成部件的復雜對象,由具體建造者來創建其各個滅部件。

  2. 抽象建造者(Builder):它是一個包含創建產品各個子部件的抽象方法的接口,通常還包含一個返回復雜產品的方法 getResult()。

  3. 具體建造者(Concrete Builder):實現 Builder 接口,完成復雜產品的各個部件的具體創建方法。

  4. 指揮者(Director):它調用建造者對象中的部件構造與裝配方法完成復雜對象的創建,在指揮者中不涉及具體產品的信息。

建造者模式的結構圖

abstract class Builder {
	public abstract void BuildPartA();
	public abstract void BuildPartB();
	public abstract Product GetResult();
}
public class Director {
	public void Construct(Builder builder) {
		builder.BuildPartA();
		builder.BuildPartB();
	}
}
public class Product {
	List parts = new ArrayList();
	
	public void Add(String part) {
		parts.add(part);
	}
	
	public void Show() {
		for (String string : parts) {
			//具體操作
		}
	}
}
public class ConcreteBuiler1 extends Builder {
	private Product product = new Product();
 
	@Override
	public void BuildPartA() {
		// 具體操作
 
	}
 
	@Override
	public void BuildPartB() {
		// 具體操作
 
	}
 
	@Override
	public Product GetResult() {
		return product;
	}
 
}
 
public class ConcreteBuiler2 extends Builder {
	private Product product = new Product();
 
	@Override
	public void BuildPartA() {
		// 具體操作
 
	}
 
	@Override
	public void BuildPartB() {
		// 具體操作
 
	}
 
	@Override
	public Product GetResult() {
		return product;
	}
 
}
public class Main {
 
	public static void main(String[] args) {
		Director director = new Director();
		Builder builder1 = new ConcreteBuiler1();
		Builder builder2 = new ConcreteBuiler2();
		
		director.Construct(builder1);
		Product product1 = builder1.GetResult();
		product1.Show();
		
		director.Construct(builder2);
		Product product = builder2.GetResult();
		product.Show();
	}
 
}
--------------------- 
作者:六小聰 
來源:CSDN 
原文:https://blog.csdn.net/DBC_121/article/details/86488568 
版權聲明:本文為博主原創文章,轉載請附上博文鏈接!


抽象工廠模式VS建造者模式的區別

我們可以將固定的邏輯操作抽象出來(Builder),然后在不同形狀的人偶實現不同的具體類(ConcreteBuilder),并為了保證依賴倒置原則,再加一個指揮生產的類,是建造過程對客戶端封閉。可能這個時候就有人會問,那這不就像是工廠模式么,抽象不同的的操作,使用工廠類生產。但是,我們要注意到,工廠模式其實就是封裝了new的“調用動作(new XXX)”,使客戶端不用按服務端的規定顯式的指定new什么,而是通過更高抽象的create函數并導入客戶端的規定來new出服務端的東西。建造者模式則是封裝了new的“實現定義(以組合的角度來確定其結構)”,使客戶端不用去接觸new里復雜的組合步驟。




摘選文字:

設計模式 https://blog.csdn.net/m0_37691414/column/info/21939

JavaScript中常用的設計模式 https://segmentfault.com/a/1190000017787537?utm_source=tag-newest



深入理解JavaScript系列/設計模式--湯姆大叔的博客
設計模式--菜鳥教程
JavaScript 中常見設計模式整理

設計模式分類 https://www.cnblogs.com/tonglingliangyong/p/3738761.html

23種設計模式的趣味理解 https://www.cnblogs.com/hegx/p/6094604.html


轉載本站文章《再談設計模式—模式23種設計模式總結》, 請注明出處:http://www.qsexmk.tw/html/theory/model/6191.html