文章目錄

• 創建者模式
• 單例設計模式
• • 單例模式的結構
  • 單例模式的實現
  • 存在的問題
  • JDK源碼解析-Runtime類
• 工廠模式
• • 概述
  • 簡單工廠模式
  • • 結構
    • 實現
    • 優缺點
    • 擴展
  • 工廠方法模式
  • • 概念
    • 結構
    • 實現
    • 優缺點
  • 抽象工廠模式
  • • 概念
    • 結構
    • 實現
    • 優缺點
    • 使用場景
  • 模式擴展
  • DK源碼解析-Collection.iterator方法
• 原型模式
• • 概述
  • 結構
  • 實現
  • 案例
  • 使用場景
  • 擴展（深克隆）
• 建造者模式
• • 概述
  • 結構
  • 實例模擬
  • 優缺點
  • 使用場景
  • 模式擴展

創建者模式

創建型模式的主要關注點是“怎樣創建對象？”，它的主要特點是“將對象的創建與使用分離”。

這樣可以降低系統的耦合度，使用者不需要關注對象的創建細節。

創建型模式分為：

• 單例模式
• 工廠方法模式
• 抽象工程模式
• 原型模式
• 建造者模式

單例設計模式

單例模式（Singleton Pattern）是 Java 中最簡單的設計模式之一。這種類型的設計模式屬于創建型模式，它提供了一種創建對象的最佳方式。

這種模式涉及到一個單一的類，該類負責創建自己的對象，同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該類的對象。

單例模式的結構

單例模式的主要有以下角色：

• 單例類。只能創建一個實例的類
• 訪問類。使用單例類

單例模式的實現

單例設計模式分類兩種：

? 餓漢式：類加載就會導致該單實例對象被創建

? 懶漢式：類加載不會導致該單實例對象被創建，而是首次使用該對象時才會創建

餓漢式-方式1（靜態變量方式）

/*** 餓漢式* 靜態變量創建類的對象*/ public class Singleton {//私有構造方法private Singleton() {}//在成員位置創建該類的對象private static Singleton instance = new Singleton();//對外提供靜態方法獲取該對象public static Singleton getInstance() {return instance;} }

說明：

?該方式在成員位置聲明Singleton類型的靜態變量，并創建Singleton類的對象instance。instance對象是隨著類的加載而創建的。如果該對象足夠大的話，而一直沒有使用就會造成內存的浪費。

餓漢式-方式2（靜態代碼塊方式）

/*** 惡漢式* 在靜態代碼塊中創建該類對象*/ public class Singleton {//私有構造方法private Singleton() {}//在成員位置創建該類的對象private static Singleton instance;static {instance = new Singleton();}//對外提供靜態方法獲取該對象public static Singleton getInstance() {return instance;} }

說明：

?該方式在成員位置聲明Singleton類型的靜態變量，而對象的創建是在靜態代碼塊中，也是對著類的加載而創建。所以和餓漢式的方式1基本上一樣，當然該方式也存在內存浪費問題。

懶漢式-方式1（線程不安全）

/*** 懶漢式* 線程不安全*/ public class Singleton {//私有構造方法private Singleton() {}//在成員位置創建該類的對象private static Singleton instance;//對外提供靜態方法獲取該對象public static Singleton getInstance() {if(instance == null) {instance = new Singleton();}return instance;} }

說明：

從上面代碼我們可以看出該方式在成員位置聲明Singleton類型的靜態變量，并沒有進行對象的賦值操作，那么什么時候賦值的呢？當調用getInstance()方法獲取Singleton類的對象的時候才創建Singleton類的對象，這樣就實現了懶加載的效果。但是，如果是多線程環境，會出現線程安全問題。

懶漢式-方式2（線程安全）

/*** 懶漢式* 線程安全*/ public class Singleton {//私有構造方法private Singleton() {}//在成員位置創建該類的對象private static Singleton instance;//對外提供靜態方法獲取該對象public static synchronized Singleton getInstance() {if(instance == null) {instance = new Singleton();}return instance;} }

說明：

?該方式也實現了懶加載效果，同時又解決了線程安全問題。但是在getInstance()方法上添加了synchronized關鍵字，導致該方法的執行效果特別低。從上面代碼我們可以看出，其實就是在初始化instance的時候才會出現線程安全問題，一旦初始化完成就不存在了。

懶漢式-方式3（雙重檢查鎖）

再來討論一下懶漢模式中加鎖的問題，對于 getInstance() 方法來說，絕大部分的操作都是讀操作，讀操作是線程安全的，所以我們沒必讓每個線程必須持有鎖才能調用該方法，我們需要調整加鎖的時機。由此也產生了一種新的實現模式：雙重檢查鎖模式

/*** 雙重檢查方式*/ public class Singleton { //私有構造方法private Singleton() {}private static Singleton instance;//對外提供靜態方法獲取該對象public static Singleton getInstance() {//第一次判斷，如果instance不為null，不進入搶鎖階段，直接返回實例if(instance == null) {synchronized (Singleton.class) {//搶到鎖之后再次判斷是否為nullif(instance == null) {instance = new Singleton();}}}return instance;} }

雙重檢查鎖模式是一種非常好的單例實現模式，解決了單例、性能、線程安全問題，上面的雙重檢測鎖模式看上去完美無缺，其實是存在問題，在多線程的情況下，可能會出現空指針問題，出現問題的原因是JVM在實例化對象的時候會進行優化和指令重排序操作。

要解決雙重檢查鎖模式帶來空指針異常的問題，只需要使用 volatile 關鍵字, volatile 關鍵字可以保證可見性和有序性。

/*** 雙重檢查方式*/ public class Singleton {//私有構造方法private Singleton() {}private static volatile Singleton instance;//對外提供靜態方法獲取該對象public static Singleton getInstance() {//第一次判斷，如果instance不為null，不進入搶鎖階段，直接返回實際if(instance == null) {synchronized (Singleton.class) {//搶到鎖之后再次判斷是否為空if(instance == null) {instance = new Singleton();}}}return instance;} }

小結：

添加 volatile 關鍵字之后的雙重檢查鎖模式是一種比較好的單例實現模式，能夠保證在多線程的情況下線程安全也不會有性能問題。

懶漢式-方式4（靜態內部類方式）

靜態內部類單例模式中實例由內部類創建，由于 JVM 在加載外部類的過程中, 是不會加載靜態內部類的, 只有內部類的屬性/方法被調用時才會被加載, 并初始化其靜態屬性。靜態屬性由于被 static 修飾，保證只被實例化一次，并且嚴格保證實例化順序。

/*** 靜態內部類方式*/ public class Singleton {//私有構造方法private Singleton() {}private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();}//對外提供靜態方法獲取該對象public static Singleton getInstance() {return SingletonHolder.INSTANCE;} }

說明：

?第一次加載Singleton類時不會去初始化INSTANCE，只有第一次調用getInstance，虛擬機加載SingletonHolder

并初始化INSTANCE，這樣不僅能確保線程安全，也能保證 Singleton 類的唯一性。

小結：

?靜態內部類單例模式是一種優秀的單例模式，是開源項目中比較常用的一種單例模式。在沒有加任何鎖的情況下，保證了多線程下的安全，并且沒有任何性能影響和空間的浪費。

枚舉方式

枚舉類實現單例模式是極力推薦的單例實現模式，因為枚舉類型是線程安全的，并且只會裝載一次，設計者充分的利用了枚舉的這個特性來實現單例模式，枚舉的寫法非常簡單，而且枚舉類型是所用單例實現中唯一一種不會被破壞的單例實現模式。

/*** 枚舉方式*/ public enum Singleton {INSTANCE; }

說明：

? 枚舉方式屬于惡漢式方式。

存在的問題

問題演示

破壞單例模式：

使上面定義的單例類（Singleton）可以創建多個對象，枚舉方式除外。有兩種方式，分別是序列化和反射。

• 序列化反序列化

  Singleton類：

  public class Singleton implements Serializable {//私有構造方法private Singleton() {}private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();}//對外提供靜態方法獲取該對象public static Singleton getInstance() {return SingletonHolder.INSTANCE;} }

  Test類：

  public class Test {public static void main(String[] args) throws Exception {//往文件中寫對象//writeObject2File();//從文件中讀取對象Singleton s1 = readObjectFromFile();Singleton s2 = readObjectFromFile();//判斷兩個反序列化后的對象是否是同一個對象System.out.println(s1 == s2);}private static Singleton readObjectFromFile() throws Exception {//創建對象輸入流對象ObjectInputStream ois = new ObjectInputStream(new FileInputStream("C:\\Users\\Think\\Desktop\\a.txt"));//第一個讀取Singleton對象Singleton instance = (Singleton) ois.readObject();return instance;}public static void writeObject2File() throws Exception {//獲取Singleton類的對象Singleton instance = Singleton.getInstance();//創建對象輸出流ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("C:\\Users\\Think\\Desktop\\a.txt"));//將instance對象寫出到文件中oos.writeObject(instance);} }

  上面代碼運行結果是false，表明序列化和反序列化已經破壞了單例設計模式。

• 反射

  Singleton類：

  public class Singleton {//私有構造方法private Singleton() {}private static volatile Singleton instance;//對外提供靜態方法獲取該對象public static Singleton getInstance() {if(instance != null) {return instance;}synchronized (Singleton.class) {if(instance != null) {return instance;}instance = new Singleton();return instance;}} }

  Test類：

  public class Test {public static void main(String[] args) throws Exception {//獲取Singleton類的字節碼對象Class clazz = Singleton.class;//獲取Singleton類的私有無參構造方法對象Constructor constructor = clazz.getDeclaredConstructor();//取消訪問檢查constructor.setAccessible(true);//創建Singleton類的對象s1Singleton s1 = (Singleton) constructor.newInstance();//創建Singleton類的對象s2Singleton s2 = (Singleton) constructor.newInstance();//判斷通過反射創建的兩個Singleton對象是否是同一個對象System.out.println(s1 == s2);} }

  上面代碼運行結果是false，表明序列化和反序列化已經破壞了單例設計模式

注意：枚舉方式不會出現這兩個問題。

問題的解決

• 序列化、反序列方式破壞單例模式的解決方法

  在Singleton類中添加readResolve()方法，在反序列化時被反射調用，如果定義了這個方法，就返回這個方法的值，如果沒有定義，則返回新new出來的對象。

  Singleton類：

  public class Singleton implements Serializable {//私有構造方法private Singleton() {}private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();}//對外提供靜態方法獲取該對象public static Singleton getInstance() {return SingletonHolder.INSTANCE;}/*** 下面是為了解決序列化反序列化破解單例模式*/private Object readResolve() {return SingletonHolder.INSTANCE;} }

  源碼解析：

  ObjectInputStream類

  public final Object readObject() throws IOException, ClassNotFoundException{...// if nested read, passHandle contains handle of enclosing objectint outerHandle = passHandle;try {Object obj = readObject0(false);//重點查看readObject0方法..... }private Object readObject0(boolean unshared) throws IOException {...try {switch (tc) {...case TC_OBJECT:return checkResolve(readOrdinaryObject(unshared));//重點查看readOrdinaryObject方法...}} finally {depth--;bin.setBlockDataMode(oldMode);} }private Object readOrdinaryObject(boolean unshared) throws IOException {...//isInstantiable 返回true，執行 desc.newInstance()，通過反射創建新的單例類，obj = desc.isInstantiable() ? desc.newInstance() : null; ...// 在Singleton類中添加 readResolve 方法后 desc.hasReadResolveMethod() 方法執行結果為trueif (obj != null && handles.lookupException(passHandle) == null && desc.hasReadResolveMethod()) {// 通過反射調用 Singleton 類中的 readResolve 方法，將返回值賦值給rep變量// 這樣多次調用ObjectInputStream類中的readObject方法，繼而就會調用我們定義的readResolve方法，所以返回的是同一個對象。Object rep = desc.invokeReadResolve(obj);...}return obj; }

• 反射方式破解單例的解決方法

  public class Singleton {//私有構造方法private Singleton() {/*反射破解單例模式需要添加的代碼*/if(instance != null) {throw new RuntimeException();}}private static volatile Singleton instance;//對外提供靜態方法獲取該對象public static Singleton getInstance() {if(instance != null) {return instance;}synchronized (Singleton.class) {if(instance != null) {return instance;}instance = new Singleton();return instance;}} }

  說明:

  ?這種方式比較好理解。當通過反射方式調用構造方法進行創建創建時，直接拋異常。不運行此中操作。

JDK源碼解析-Runtime類

Runtime類就是使用的單例設計模式。

通過源代碼查看使用的是哪兒種單例模式

public class Runtime {private static Runtime currentRuntime = new Runtime();/*** Returns the runtime object associated with the current Java application.* Most of the methods of class <code>Runtime</code> are instance* methods and must be invoked with respect to the current runtime object.** @return the <code>Runtime</code> object associated with the current* Java application.*/public static Runtime getRuntime() {return currentRuntime;}/** Don't let anyone else instantiate this class */private Runtime() {}... }

從上面源代碼中可以看出Runtime類使用的是惡漢式（靜態屬性）方式來實現單例模式的。

使用Runtime類中的方法

public class RuntimeDemo {public static void main(String[] args) throws IOException {//獲取Runtime類對象Runtime runtime = Runtime.getRuntime();//返回 Java 虛擬機中的內存總量。System.out.println(runtime.totalMemory());//返回 Java 虛擬機試圖使用的最大內存量。System.out.println(runtime.maxMemory());//創建一個新的進程執行指定的字符串命令，返回進程對象Process process = runtime.exec("ipconfig");//獲取命令執行后的結果，通過輸入流獲取InputStream inputStream = process.getInputStream();byte[] arr = new byte[1024 * 1024* 100];int b = inputStream.read(arr);System.out.println(new String(arr,0,b,"gbk"));} }

工廠模式

概述

需求：設計一個咖啡店點餐系統。

設計一個咖啡類（Coffee），并定義其兩個子類（美式咖啡【AmericanCoffee】和拿鐵咖啡【LatteCoffee】）；再設計一個咖啡店類（CoffeeStore），咖啡店具有點咖啡的功能。

具體類的設計如下：

在java中，萬物皆對象，這些對象都需要創建，如果創建的時候直接new該對象，就會對該對象耦合嚴重，假如我們要更換對象，所有new對象的地方都需要修改一遍，這顯然違背了軟件設計的開閉原則。如果我們使用工廠來生產對象，我們就只和工廠打交道就可以了，徹底和對象解耦，如果要更換對象，直接在工廠里更換該對象即可，達到了與對象解耦的目的；所以說，工廠模式最大的優點就是：解耦。

這里會介紹三種工廠的使用

• 簡單工廠模式（不屬于GOF的23種經典設計模式）
• 工廠方法模式
• 抽象工廠模式

簡單工廠模式

簡單工廠不是一種設計模式，反而比較像是一種編程習慣。

結構

簡單工廠包含如下角色：

• 抽象產品 ：定義了產品的規范，描述了產品的主要特性和功能。
• 具體產品 ：實現或者繼承抽象產品的子類
• 具體工廠 ：提供了創建產品的方法，調用者通過該方法來獲取產品。

實現

現在使用簡單工廠對上面案例進行改進，類圖如下：

工廠類代碼如下：

public class SimpleCoffeeFactory {public Coffee createCoffee(String type) {Coffee coffee = null;if("americano".equals(type)) {coffee = new AmericanoCoffee();} else if("latte".equals(type)) {coffee = new LatteCoffee();}return coffee;} }

工廠（factory）處理創建對象的細節，一旦有了SimpleCoffeeFactory，CoffeeStore類中的orderCoffee()就變成此對象的客戶，后期如果需要Coffee對象直接從工廠中獲取即可。這樣也就解除了和Coffee實現類的耦合，同時又產生了新的耦合，CoffeeStore對象和SimpleCoffeeFactory工廠對象的耦合，工廠對象和商品對象的耦合。

后期如果再加新品種的咖啡，我們勢必要需求修改SimpleCoffeeFactory的代碼，違反了開閉原則。工廠類的客戶端可能有很多，比如創建美團外賣等，這樣只需要修改工廠類的代碼，省去其他的修改操作。

優缺點

優點：

封裝了創建對象的過程，可以通過參數直接獲取對象。把對象的創建和業務邏輯層分開，這樣以后就避免了修改客戶代碼，如果要實現新產品直接修改工廠類，而不需要在原代碼中修改，這樣就降低了客戶代碼修改的可能性，更加容易擴展。

缺點：

增加新產品時還是需要修改工廠類的代碼，違背了“開閉原則”。

擴展

靜態工廠

在開發中也有一部分人將工廠類中的創建對象的功能定義為靜態的，這個就是靜態工廠模式，它也不是23種設計模式中的。代碼如下：

public class SimpleCoffeeFactory {public static Coffee createCoffee(String type) {Coffee coffee = null;if("americano".equals(type)) {coffee = new AmericanoCoffee();} else if("latte".equals(type)) {coffee = new LatteCoffee();}return coffe;} }

工廠方法模式

針對上例中的缺點，使用工廠方法模式就可以完美的解決，完全遵循開閉原則。

概念

定義一個用于創建對象的接口，讓子類決定實例化哪個產品類對象。工廠方法使一個產品類的實例化延遲到其工廠的子類。

結構

工廠方法模式的主要角色：

• 抽象工廠（Abstract Factory）：提供了創建產品的接口，調用者通過它訪問具體工廠的工廠方法來創建產品。
• 具體工廠（ConcreteFactory）：主要是實現抽象工廠中的抽象方法，完成具體產品的創建。
• 抽象產品（Product）：定義了產品的規范，描述了產品的主要特性和功能。
• 具體產品（ConcreteProduct）：實現了抽象產品角色所定義的接口，由具體工廠來創建，它同具體工廠之間一一對應。

實現

使用工廠方法模式對上例進行改進，類圖如下：

代碼如下：

抽象工廠：

public interface CoffeeFactory {Coffee createCoffee(); }

具體工廠：

public class LatteCoffeeFactory implements CoffeeFactory {public Coffee createCoffee() {return new LatteCoffee();} }public class AmericanCoffeeFactory implements CoffeeFactory {public Coffee createCoffee() {return new AmericanCoffee();} }

咖啡店類：

public class CoffeeStore {private CoffeeFactory factory;public CoffeeStore(CoffeeFactory factory) {this.factory = factory;}public Coffee orderCoffee(String type) {Coffee coffee = factory.createCoffee();coffee.addMilk();coffee.addsugar();return coffee;} }

從以上的編寫的代碼可以看到，要增加產品類時也要相應地增加工廠類，不需要修改工廠類的代碼了，這樣就解決了簡單工廠模式的缺點。

工廠方法模式是簡單工廠模式的進一步抽象。由于使用了多態性，工廠方法模式保持了簡單工廠模式的優點，而且克服了它的缺點。

優缺點

優點：

• 用戶只需要知道具體工廠的名稱就可得到所要的產品，無須知道產品的具體創建過程；
• 在系統增加新的產品時只需要添加具體產品類和對應的具體工廠類，無須對原工廠進行任何修改，滿足開閉原則；

缺點：

• 每增加一個產品就要增加一個具體產品類和一個對應的具體工廠類，這增加了系統的復雜度。

抽象工廠模式

前面介紹的工廠方法模式中考慮的是一類產品的生產，如畜牧場只養動物、電視機廠只生產電視機。

這些工廠只生產同種類產品，同種類產品稱為同等級產品，也就是說：工廠方法模式只考慮生產同等級的產品，但是在現實生活中許多工廠是綜合型的工廠，能生產多等級（種類） 的產品，如電器廠既生產電視機又生產洗衣機或空調，大學既有軟件專業又有生物專業等。

本節要介紹的抽象工廠模式將考慮多等級產品的生產，將同一個具體工廠所生產的位于不同等級的一組產品稱為一個產品族，下圖所示橫軸是產品等級，也就是同一類產品；縱軸是產品族，也就是同一品牌的產品，同一品牌的產品產自同一個工廠。

概念

是一種為訪問類提供一個創建一組相關或相互依賴對象的接口，且訪問類無須指定所要產品的具體類就能得到同族的不同等級的產品的模式結構。

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

結構

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

• 抽象工廠（Abstract Factory）：提供了創建產品的接口，它包含多個創建產品的方法，可以創建多個不同等級的產品。
• 具體工廠（Concrete Factory）：主要是實現抽象工廠中的多個抽象方法，完成具體產品的創建。
• 抽象產品（Product）：定義了產品的規范，描述了產品的主要特性和功能，抽象工廠模式有多個抽象產品。
• 具體產品（ConcreteProduct）：實現了抽象產品角色所定義的接口，由具體工廠來創建，它 同具體工廠之間是多對一的關系。

實現

現咖啡店業務發生改變，不僅要生產咖啡還要生產甜點，如提拉米蘇、抹茶慕斯等，要是按照工廠方法模式，需要定義提拉米蘇類、抹茶慕斯類、提拉米蘇工廠、抹茶慕斯工廠、甜點工廠類，很容易發生類爆炸情況。其中拿鐵咖啡、美式咖啡是一個產品等級，都是咖啡；提拉米蘇、抹茶慕斯也是一個產品等級；拿鐵咖啡和提拉米蘇是同一產品族（也就是都屬于意大利風味），美式咖啡和抹茶慕斯是同一產品族（也就是都屬于美式風味）。所以這個案例可以使用抽象工廠模式實現。類圖如下：

代碼如下：

抽象工廠：

public interface DessertFactory {Coffee createCoffee();Dessert createDessert(); }

具體工廠：

//美式甜點工廠 public class AmericanDessertFactory implements DessertFactory {public Coffee createCoffee() {return new AmericanCoffee();}public Dessert createDessert() {return new MatchaMousse();} } //意大利風味甜點工廠 public class ItalyDessertFactory implements DessertFactory {public Coffee createCoffee() {return new LatteCoffee();}public Dessert createDessert() {return new Tiramisu();} }

如果要加同一個產品族的話，只需要再加一個對應的工廠類即可，不需要修改其他的類。

優缺點

優點：

當一個產品族中的多個對象被設計成一起工作時，它能保證客戶端始終只使用同一個產品族中的對象。

缺點：

當產品族中需要增加一個新的產品時，所有的工廠類都需要進行修改。

使用場景

• 當需要創建的對象是一系列相互關聯或相互依賴的產品族時，如電器工廠中的電視機、洗衣機、空調等。

• 系統中有多個產品族，但每次只使用其中的某一族產品。如有人只喜歡穿某一個品牌的衣服和鞋。

• 系統中提供了產品的類庫，且所有產品的接口相同，客戶端不依賴產品實例的創建細節和內部結構。

如：輸入法換皮膚，一整套一起換。生成不同操作系統的程序。

模式擴展

簡單工廠+配置文件解除耦合

可以通過工廠模式+配置文件的方式解除工廠對象和產品對象的耦合。在工廠類中加載配置文件中的全類名，并創建對象進行存儲，客戶端如果需要對象，直接進行獲取即可。

第一步：定義配置文件

為了演示方便，我們使用properties文件作為配置文件，名稱為bean.properties

american=com.itheima.pattern.factory.config_factory.AmericanCoffee latte=com.itheima.pattern.factory.config_factory.LatteCoffee

第二步：改進工廠類

public class CoffeeFactory {private static Map<String,Coffee> map = new HashMap();static {Properties p = new Properties();InputStream is = CoffeeFactory.class.getClassLoader().getResourceAsStream("bean.properties");try {p.load(is);//遍歷Properties集合對象Set<Object> keys = p.keySet();for (Object key : keys) {//根據鍵獲取值（全類名）String className = p.getProperty((String) key);//獲取字節碼對象Class clazz = Class.forName(className);Coffee obj = (Coffee) clazz.newInstance();map.put((String)key,obj);}} catch (Exception e) {e.printStackTrace();}}public static Coffee createCoffee(String name) {return map.get(name);} }

靜態成員變量用來存儲創建的對象（鍵存儲的是名稱，值存儲的是對應的對象），而讀取配置文件以及創建對象寫在靜態代碼塊中，目的就是只需要執行一次。

DK源碼解析-Collection.iterator方法

public class Demo {public static void main(String[] args) {List<String> list = new ArrayList<>();list.add("令狐沖");list.add("風清揚");list.add("任我行");//獲取迭代器對象Iterator<String> it = list.iterator();//使用迭代器遍歷while(it.hasNext()) {String ele = it.next();System.out.println(ele);}} }

對上面的代碼大家應該很熟，使用迭代器遍歷集合，獲取集合中的元素。而單列集合獲取迭代器的方法就使用到了工廠方法模式。我們看通過類圖看看結構：

Collection接口是抽象工廠類，ArrayList是具體的工廠類；Iterator接口是抽象商品類，ArrayList類中的Iter內部類是具體的商品類。在具體的工廠類中iterator()方法創建具體的商品類的對象。

另：

? 1,DateForamt類中的getInstance()方法使用的是工廠模式；

? 2,Calendar類中的getInstance()方法使用的是工廠模式；

原型模式

概述

用一個已經創建的實例作為原型，通過復制該原型對象來創建一個和原型對象相同的新對象。

結構

原型模式包含如下角色：

• 抽象原型類：規定了具體原型對象必須實現的的 clone() 方法。
• 具體原型類：實現抽象原型類的 clone() 方法，它是可被復制的對象。
• 訪問類：使用具體原型類中的 clone() 方法來復制新的對象。

接口類圖如下：

實現

原型模式的克隆分為淺克隆和深克隆。

淺克隆：創建一個新對象，新對象的屬性和原來對象完全相同，對于非基本類型屬性，仍指向原有屬性所指向的對象的內存地址。

深克隆：創建一個新對象，屬性中引用的其他對象也會被克隆，不再指向原有對象地址。

Java中的Object類中提供了 clone() 方法來實現淺克隆。 Cloneable 接口是上面的類圖中的抽象原型類，而實現了Cloneable接口的子實現類就是具體的原型類。代碼如下：

Realizetype（具體的原型類）：

public class Realizetype implements Cloneable {public Realizetype() {System.out.println("具體的原型對象創建完成！");}@Overrideprotected Realizetype clone() throws CloneNotSupportedException {System.out.println("具體原型復制成功！");return (Realizetype) super.clone();} }

PrototypeTest（測試訪問類）：

public class PrototypeTest {public static void main(String[] args) throws CloneNotSupportedException {Realizetype r1 = new Realizetype();Realizetype r2 = r1.clone();System.out.println("對象r1和r2是同一個對象？" + (r1 == r2));} }

根據結果我們可以知道clone的底層并不是通過new一個新對象的方式。

案例

用原型模式生成“三好學生”獎狀

同一學校的“三好學生”獎狀除了獲獎人姓名不同，其他都相同，可以使用原型模式復制多個“三好學生”獎狀出來，然后在修改獎狀上的名字即可。

類圖如下：

代碼如下：

//獎狀類 public class Citation implements Cloneable {private String name;public void setName(String name) {this.name = name;}public String getName() {return (this.name);}public void show() {System.out.println(name + "同學：在2020學年第一學期中表現優秀，被評為三好學生。特發此狀！");}@Overridepublic Citation clone() throws CloneNotSupportedException {return (Citation) super.clone();} }//測試訪問類 public class CitationTest {public static void main(String[] args) throws CloneNotSupportedException {Citation c1 = new Citation();c1.setName("張三");//復制獎狀Citation c2 = c1.clone();//將獎狀的名字修改李四c2.setName("李四");c1.show();c2.show();} }

使用場景

• 對象的創建非常復雜，可以使用原型模式快捷的創建對象。
• 性能和安全要求比較高。

擴展（深克隆）

將上面的“三好學生”獎狀的案例中Citation類的name屬性修改為Student類型的屬性。代碼如下：

//獎狀類 public class Citation implements Cloneable {private Student stu;public Student getStu() {return stu;}public void setStu(Student stu) {this.stu = stu;}void show() {System.out.println(stu.getName() + "同學：在2020學年第一學期中表現優秀，被評為三好學生。特發此狀！");}@Overridepublic Citation clone() throws CloneNotSupportedException {return (Citation) super.clone();} }//學生類 public class Student {private String name;private String address;public Student(String name, String address) {this.name = name;this.address = address;}public Student() {}public String getName() {return name;}public void setName(String name) {this.name = name;}public String getAddress() {return address;}public void setAddress(String address) {this.address = address;} }//測試類 public class CitationTest {public static void main(String[] args) throws CloneNotSupportedException {Citation c1 = new Citation();Student stu = new Student("張三", "西安");c1.setStu(stu);//復制獎狀Citation c2 = c1.clone();//獲取c2獎狀所屬學生對象Student stu1 = c2.getStu();stu1.setName("李四");//判斷stu對象和stu1對象是否是同一個對象System.out.println("stu和stu1是同一個對象？" + (stu == stu1));c1.show();c2.show();} }

運行結果為：

說明：

?stu對象和stu1對象是同一個對象，就會產生將stu1對象中name屬性值改為“李四”，兩個Citation（獎狀）對象中顯示的都是李四。這就是淺克隆的效果，對具體原型類（Citation）中的引用類型的屬性進行引用的復制。這種情況需要使用深克隆，而進行深克隆需要使用對象流。代碼如下：

public class CitationTest1 {public static void main(String[] args) throws Exception {Citation c1 = new Citation();Student stu = new Student("張三", "西安");c1.setStu(stu);//創建對象輸出流對象ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("C:\\Users\\Think\\Desktop\\b.txt"));//將c1對象寫出到文件中oos.writeObject(c1);oos.close();//創建對象出入流對象ObjectInputStream ois = new ObjectInputStream(new FileInputStream("C:\\Users\\Think\\Desktop\\b.txt"));//讀取對象Citation c2 = (Citation) ois.readObject();//獲取c2獎狀所屬學生對象Student stu1 = c2.getStu();stu1.setName("李四");//判斷stu對象和stu1對象是否是同一個對象System.out.println("stu和stu1是同一個對象？" + (stu == stu1));c1.show();c2.show();} }

運行結果為：

注意：Citation類和Student類必須實現Serializable接口，否則會拋NotSerializableException異常。

建造者模式

概述

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

• 分離了部件的構造(由Builder來負責)和裝配(由Director負責)。 從而可以構造出復雜的對象。
• 這個模式適用于：某個對象的構建過程復雜的情況。
• 由于實現了構建和裝配的解耦。不同的構建器，相同的裝配，也可以做出不同的對象；相同的構建器，不同的裝配順序也可以做出不同的對象。也就是實現了構建算法、裝配算法的解耦，實現了更好的復用。
• 建造者模式可以將部件和其組裝過程分開，一步一步創建一個復雜的對象。用戶只需要指定復雜對象的類型就可以得到該對象，而無須知道其內部的具體構造細節。

結構

建造者（Builder）模式包含如下角色：

• 抽象建造者類（Builder）：這個接口規定要實現復雜對象的哪些部分的創建，并不涉及具體的部件對象的創建。

• 具體建造者類（ConcreteBuilder）：實現 Builder 接口，完成復雜產品的各個部件的具體創建方法。在構造過程完成后，提供產品的實例。

• 產品類（Product）：要創建的復雜對象。

• 指揮者類（Director）：調用具體建造者來創建復雜對象的各個部分，在指導者中不涉及具體產品的信息，只負責保證對象各部分完整創建或按某種順序創建。

類圖如下：

實例模擬

創建共享單車

生產自行車是一個復雜的過程，它包含了車架，車座等組件的生產。而車架又有碳纖維，鋁合金等材質的，車座有橡膠，真皮等材質。對于自行車的生產就可以使用建造者模式。

這里Bike是產品，包含車架，車座等組件；Builder是抽象建造者，MobikeBuilder和OfoBuilder是具體的建造者；Director是指揮者。類圖如下：

具體的代碼如下：

建造者模式中的產品類:

public class Bike {private String frame;private String seat;public String getSeat() {return seat;}public void setSeat(String seat) {this.seat = seat;}public String getFrame() {return frame;}public void setFrame(String frame) {this.frame = frame;}@Overridepublic String toString() {return "Bike{" +"frame='" + frame + '\'' +", seat='" + seat + '\'' +'}';} }

建造者模式中的抽象建造者類:

public abstract class Builder {protected Bike myBike = new Bike();public abstract void buildFrame();public abstract void buildSeat();public abstract Bike createBike(); }

摩拜的具體建造者類:

public class MobikeBuilder extends Builder{public void buildFrame() {myBike.setFrame("摩拜專用車架");}public void buildSeat() {myBike.setSeat("摩拜專用車座");}public Bike createBike() {return myBike;} }

Ofo的具體建造者類:

public class OfoBuilder extends Builder {public void buildFrame() {myBike.setFrame("Ofo專用車架");}public void buildSeat() {myBike.setSeat("Ofo專用車座");}public Bike createBike() {return myBike;} }

建造者模式中的指揮者類:

public class Director {private Builder myBuilder;public Director(Builder myBuilder) {this.myBuilder = myBuilder;}public Bike construct(){myBuilder.buildFrame();myBuilder.buildSeat();return myBuilder.createBike();} }

測試：

public class Client {public static void main(String[] args) {Director director = new Director(new OfoBuilder());Bike bike = director.construct();System.out.println(bike);} }

注意：

上面示例是 Builder模式的常規用法，指揮者類 Director 在建造者模式中具有很重要的作用，它用于指導具體構建者如何構建產品，控制調用先后次序，并向調用者返回完整的產品類，但是有些情況下需要簡化系統結構，可以把指揮者類和抽象建造者進行結合

// 抽象 builder 類 public abstract class Builder {protected Bike mBike = new Bike();public abstract void buildFrame();public abstract void buildSeat();public abstract Bike createBike();public Bike construct() {this.buildFrame();this.BuildSeat();return this.createBike();} }

說明：

這樣做確實簡化了系統結構，但同時也加重了抽象建造者類的職責，也不是太符合單一職責原則，如果construct() 過于復雜，建議還是封裝到 Director 中。

優缺點

優點：

• 建造者模式的封裝性很好。使用建造者模式可以有效的封裝變化，在使用建造者模式的場景中，一般產品類和建造者類是比較穩定的，因此，將主要的業務邏輯封裝在指揮者類中對整體而言可以取得比較好的穩定性。
• 在建造者模式中，客戶端不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象。
• 可以更加精細地控制產品的創建過程 。將復雜產品的創建步驟分解在不同的方法中，使得創建過程更加清晰，也更方便使用程序來控制創建過程。
• 建造者模式很容易進行擴展。如果有新的需求，通過實現一個新的建造者類就可以完成，基本上不用修改之前已經測試通過的代碼，因此也就不會對原有功能引入風險。符合開閉原則。

缺點：

造者模式所創建的產品一般具有較多的共同點，其組成部分相似，如果產品之間的差異性很大，則不適合使用建造者模式，因此其使用范圍受到一定的限制。

使用場景

建造者（Builder）模式創建的是復雜對象，其產品的各個部分經常面臨著劇烈的變化，但將它們組合在一起的算法卻相對穩定，所以它通常在以下場合使用。

• 創建的對象較復雜，由多個部件構成，各部件面臨著復雜的變化，但構件間的建造順序是穩定的。
• 創建復雜對象的算法獨立于該對象的組成部分以及它們的裝配方式，即產品的構建過程和最終的表示是獨立的。

模式擴展

建造者模式除了上面的用途外，在開發中還有一個常用的使用方式，就是當一個類構造器需要傳入很多參數時，如果創建這個類的實例，代碼可讀性會非常差，而且很容易引入錯誤，此時就可以利用建造者模式進行重構。

重構前代碼如下：

public class Phone {private String cpu;private String screen;private String memory;private String mainboard;public Phone(String cpu, String screen, String memory, String mainboard) {this.cpu = cpu;this.screen = screen;this.memory = memory;this.mainboard = mainboard;}public String getCpu() {return cpu;}public void setCpu(String cpu) {this.cpu = cpu;}public String getScreen() {return screen;}public void setScreen(String screen) {this.screen = screen;}public String getMemory() {return memory;}public void setMemory(String memory) {this.memory = memory;}public String getMainboard() {return mainboard;}public void setMainboard(String mainboard) {this.mainboard = mainboard;}@Overridepublic String toString() {return "Phone{" +"cpu='" + cpu + '\'' +", screen='" + screen + '\'' +", memory='" + memory + '\'' +", mainboard='" + mainboard + '\'' +'}';} }public class Client {public static void main(String[] args) {//構建Phone對象Phone phone = new Phone("intel","三星屏幕","金士頓","華碩");System.out.println(phone);} }

上面在客戶端代碼中構建Phone對象，傳遞了四個參數，如果參數更多呢？代碼的可讀性及使用的成本就是比較高。

重構后代碼：

public class Phone {private String cpu;private String screen;private String memory;private String mainboard;private Phone(Builder builder) {cpu = builder.cpu;screen = builder.screen;memory = builder.memory;mainboard = builder.mainboard;}public static final class Builder {private String cpu;private String screen;private String memory;private String mainboard;public Builder() {}public Builder cpu(String val) {cpu = val;return this;}public Builder screen(String val) {screen = val;return this;}public Builder memory(String val) {memory = val;return this;}public Builder mainboard(String val) {mainboard = val;return this;}public Phone build() {return new Phone(this);}}@Overridepublic String toString() {return "Phone{" +"cpu='" + cpu + '\'' +", screen='" + screen + '\'' +", memory='" + memory + '\'' +", mainboard='" + mainboard + '\'' +'}';} }public class Client {public static void main(String[] args) {Phone phone = new Phone.Builder().cpu("intel").mainboard("華碩").memory("金士頓").screen("三星").build();System.out.println(phone);} }

這種方式就是相當于把指揮者類集成在了建造者類中，并且把建造者類使用內部類的形式進行表示。其建造者模式的核心并未發生改變。

重構后的代碼在使用起來更方便，某種程度上也可以提高開發效率。從軟件設計上，對程序員的要求比較高。

這種做法與原來建造者的方式相比：

• 構建的組件一目了然
• 構建的順序由指揮者轉向了客戶

總結

以上是生活随笔為你收集整理的【设计模式】五种创建者模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。