设计模式-创建者模式篇
設計模式
目錄:
一、單例模式
二、工廠模式
三、抽象工廠模式
四、原型模式
五、建造者模式
注:學習視頻:黑馬程序員Java設計模式
創建者模式
創建型模式的主要關注點是“怎樣創建對象?”,它的主要特點是“將對象的創建與使用分離”。
這樣可以降低系統的耦合度,使用者不需要關注對象的創建細節。
創建模式分為:
- 單例模式
- 工廠方法模式
- 抽象工廠模式
- 原型模式
- 建造者模式
一、單例設計模式
單例模式(Singleton Pattern)是 Java 中最簡單的設計模式之一。這種類型的設計模式屬于創建型模式,它提供了一種創建對象的最佳方式。
這種模式涉及到一個單一的類,該類負責創建自己的對象,同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式,可以直接訪問,不需要實例化該類的對象。
1.1 單例設計模式結構
單例模式主要有以下角色:
- 單例類。只能創建一個實例的類
- 訪問類。使用單單例類
1.2 單例模式的實現
單例模式設計模式分兩種:
? 餓漢式:類加載就會導致該單例對象被創建。
? 懶漢式:類加載不會導致單例對象被創建,而是首次調用該對象時才會被創建
1.2.1 餓漢式
1. 餓漢式:方式1(靜態變量方式):
靜態成員變量方式可以實現,是因為靜態變量只有在類加載的時候被初始化一次。
/*** 餓漢式(靜態成員變量)*/ public class Singleton {// 將構造器私有化private Singleton(){}// 創建靜態成員變量private static Singleton instance = new Singleton();// 提供獲取靜態成員變量方法public static Singleton getInstance(){return instance;} }說明:
該方式在成員位置聲明Singleton類型的靜態變量,并創建Singleton類的對象instance。instance對象是隨著類的加載而創建的。如果該對象足夠大的話,而一直沒有使用就會造成內存的浪費。
2. 餓漢式:方式2(靜態代碼塊):
/*** 餓漢式(靜態代碼塊)*/ public class Singleton {// 私有化構造方法private Singleton(){}// 聲明靜態實例對象private static Singleton instance;static {instance = new Singleton();}// 提供獲取靜態成員變量方法public static Singleton getInstance(){return instance;} }說明:
該方式在成員位置聲明Singleton類型的靜態變量,而對象的創建是在靜態代碼塊中,也是對著類的加載而創建。所以和餓漢式的方式1基本上一樣,當然該方式也存在內存浪費問題。
1.2.2 懶漢式
1. 懶漢式-方式1(線程不安全)
/*** 懶漢式(線程不完全)*/ public class Singleton {//私有化構造器private Singleton(){}// 聲明靜態變量private static Singleton instance;public static Singleton getInstance() {if(instance == null){// 線程1進入,又切換到了線程2 會導致兩個線程進入,破壞了單例模式instance = new Singleton();}return instance;} }說明:
線程不完全問題,如果一個線程進入了判斷是否為null,這個時候被切換到另一個進程,這樣的話,有兩個進入了判斷,創建了兩個實例,就不是單例模式了。
2.懶漢式-方式2(線程安全)
/*** 懶漢式(線程不完全)*/ public class Singleton {//私有化構造器private Singleton(){}// 聲明靜態變量private static Singleton instance;public static synchronized Singleton getInstance() {if(instance == null){// 線程1進入,又切換到了線程2 會導致兩個線程進入,破壞了單例模式instance = new Singleton();}return instance;} }說明:
線程安全的方式只是在線程不安全的方式基礎上,在獲取實例的方法上加上了synchronized關鍵字,保證了線程安全。
3.懶漢式-方式3(雙重檢查鎖)
/*** 懶漢式雙重檢查鎖*/ public class Singleton {// 私有化構造方法private Singleton(){}// 聲明靜態變量private static Singleton instance;// 獲取方法public static Singleton getInstance() {// 第一判斷,如果instance不等于null,就不進入搶鎖階段,// 這樣的話可以節省搶鎖的時間,提高性能if(instance == null){synchronized (Singleton.class){// 搶到鎖之后再進入判斷是否為null 不是則直接返回instanceif(instance == null){instance = new Singleton();}}}return instance;} }說明:
雙重檢查鎖,實際上是通過線程安全鎖的思想上來改進的,將搶鎖時機改變,如果instance為null,則不進入搶鎖,直接返回,這樣一來節省了搶鎖的時間,所有性能也提高了。
但是仍然存在一定的問題,在多線程的情況下,可能會出現空指針問題,出現問題的原因是JVM在實例化對象的時候會進行優化和指令重排序操作。
改進:
可以使用volatile關鍵字可以保證可見性和有序性
/*** 懶漢式雙重檢查鎖*/ public class Singleton {// 私有化構造方法private Singleton(){}// 聲明靜態變量private static volatile Singleton instance;// 獲取方法public static Singleton getInstance() {// 第一判斷,如果instance不等于null,就不進入搶鎖階段,// 這樣的話可以節省搶鎖的時間,提高性能if(instance == null){synchronized (Singleton.class){// 搶到鎖之后再進入判斷是否為null 不是則直接返回instanceif(instance == null){instance = new Singleton();}}}return instance;} }4.懶漢式-方式4(靜態內部類方式)
靜態內部類單例模式中實例由內部類創建,由于 JVM 在加載外部類的過程中, 是不會加載靜態內部類的, 只有內部類的屬性/方法被調用時才會被加載, 并初始化其靜態屬性。靜態屬性由于被 static 修飾,保證只被實例化一次,并且嚴格保證實例化順序。
/*** 懶漢式(靜態內部類)*/ public class Singleton {// 私有構造方法private Singleton(){}// 定義靜態內部public static class SingletonInter{// 聲明靜態變量 防止外面修改 instance 可以加上finalprivate static final Singleton INSTANCE = new Singleton();}// 對外提供靜態方法獲取該對象public static Singleton getInstance(){return SingletonInter.INSTANCE;} }說明:
第一次加載的時候,由于INSTANCE 是寫在靜態內部類里面的,所有不會加載該變量,這樣就實現了餓漢式,因為SingletonInter 是靜態內部類,在第一次調用的時候,對他進行加載,后面調用將不會再加載,所以是線程安全的。
1.2.3 枚舉方式
枚舉類實現單例模式是極力推薦的單例實現模式,因為枚舉類型是線程安全的,并且只會裝載一次,設計者充分的利用了枚舉的這個特性來實現單例模式,枚舉的寫法非常簡單,而且枚舉類型是所用單例實現中唯一一種不會被破壞的單例實現模式。
/*** 枚舉方式*/ public enum Singleton {INSTANCE; }說明:
枚舉方式屬于餓漢式
1.3 存在問題及解決方案
破壞單例模式:使上面定義的單例類(Singleton)可以創建多個對象,枚舉方式除外。
有兩種方式,分別是序列化和反射。
1.3.1 序列化和反序列化
采用靜態內部類演示,其他單例模式實現方式也存在同樣問題
- Singleton類
- Test測試類
實現破壞單例模式的方法,將獲取的單例對象instance寫入到文件中,再從文件中讀取對象,連續讀取兩次獲取兩個instance,這兩個對象不是同一個對象,就破壞了單例模式。
public class Test {public static void main(String[] args) throws IOException, ClassNotFoundException {writeObjectToFile();readObjectFromFile();readObjectFromFile();/*** 輸入如下,不是同一個對象,已經破壞了單例模式*com.zcc.singleton.dome5.Singleton@312b1dae* com.zcc.singleton.dome5.Singleton@7530d0a*/}/***將對象寫入文件* @throws IOException*/public static void writeObjectToFile() throws IOException {Singleton instance = Singleton.getInstance();ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("C:\\Users\\安逸i\\Desktop\\a.txt"));oos.writeObject(instance);}/*** 從文件中讀取出對象* @throws IOException* @throws ClassNotFoundException*/public static void readObjectFromFile() throws IOException, ClassNotFoundException {ObjectInputStream ooi = new ObjectInputStream(new FileInputStream("C:\\Users\\安逸i\\Desktop\\a.txt"));Singleton instance = (Singleton) ooi.readObject();System.out.println(instance);} }- 序列化、反序列方式破壞單例模式的解決方法
在Singleton類中添加readResolve()方法,在底層中反序列化的時候會檢查該對象是否有readResolve(),如果定義了這個方法,就返回這個方法的值,如果沒有定義,則返回新new出來的對象。其實在底層原理中反序列化的時候會檢查該對象。
- **修改Singleton類,添加readResolve方法 **
- 再次執行測試類返回結果
com.zcc.singleton.dome5.Singleton@3764951d
com.zcc.singleton.dome5.Singleton@3764951d
1.3.2 反射
- Singleton類
- Test類
- 反射方式破壞單例模式的解決方法
思路: 既然是通過調用無參構造器來創建的對象,那就可以從無參構造器下手,判斷是否已經存在對象,為了解決線程安全的問題,采用synchronized 來實現線程安全
- 改進后的Singletonl類
- 再次運行Test類
Exception in thread “main” java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at com.zcc.singleton.dome6.Test.main(Test.java:20)
Caused by: java.lang.RuntimeException: 不能創建多個對象
at com.zcc.singleton.dome6.Singleton.(Singleton.java:16)
… 5 more
二、 工廠模式
2.1 概述
需求:設計一個咖啡店點餐系統。
設計一個咖啡類(Coffee),并定義其兩個子類(美式咖啡【AmericanCoffee】和拿鐵咖啡【LatteCoffee】);再設計一個咖啡店類(CoffeeStore),咖啡店具有點咖啡的功能。
具體設計如下:
三種工廠模式:
簡單工廠模式(不屬于GOF的23種經典設計模式)
工廠模式
抽象工廠模式
2.2 簡單工廠模式
簡單工廠不是一張設計模式,像是一種變成習慣
2.2.1 結構
簡單工廠包含如下角色:
- 抽象產品:定義產品的規范,描述產品的主要特性和功能
- 具體產品:實現或集成抽象產品子類
- 具體工廠:提供創建產品的方法,調用者通過該方法獲取產品
2.2.2 實現
工廠類代碼:
public class SimpleFactory {// 傳入咖啡類型,創建對應的咖啡// 具體工廠創建具體產品,返回抽象產品public Coffee createCoffee(String typeName){Coffee coffee = null;if(typeName.equals("americano")){coffee = new AmericanoCoffee();}else if(typeName.equals("latte")){coffee = new LatteCoffee();}else {throw new RuntimeException("沒有你點的咖啡");}return coffee;} }說明:
創建了工廠之后,對于咖啡店來說,就可以通過名字來直接調用工廠的方法來獲得對象,將創建過程封裝了起來,降低了耦合度,但是也伴隨的新的耦合產生,對于咖啡店和工廠對象之間的耦合,工廠對象和商品對象的耦合。
2.2.3 優缺點
- 優點:
封裝了創建對象的過程,客戶可以通過參數直接獲得對象,這樣的話,減少了客戶代碼修改的可能,不需要客戶來直接創建對象。
- 缺點:
還是違背了“開閉原則”,如果需要增加一個具體產品,則需要修改的工廠類,違背了開閉原則。
2.3 工廠方法模式
針對于簡單工廠模式,使用工廠方法模式就可以完美解決,完成遵循開閉原則。
2.3.1 概念
定義一個用于創建對象的接口,讓子類決定實例化哪一個產品類都西昂,工廠方式使一個產品的實例化延遲到了子類。
2.3.2 結構
工廠方法模式的主要角色:
- 抽象工廠:提供創建產品接口,調用者通過它的是實現類,來創建具體工廠來創建具體產品
- 具體工廠:主要是是實現抽象工廠的方法,創建對應的具體產品
- 抽象產品:定義產品的規范,描述了產品的功能和特性
- 具體產品: 實現抽象產品,由具體工廠來創建,它和具體工廠是一對一的關系
2.3.4 實現
代碼如下:
- 抽象工廠:
- 具體工廠
- 咖啡店(CoffeeStore)
- CoffeeStore
說明:
可以看到,這樣設計的話,如果需要增加一個產品類時,雖然使不會改變原來的代碼,但是每增加一個產品,就要增加產品類,和對應的具體工廠類,如果類的數量比較大,就會造成類爆炸問題。
2.3.5 優缺點
優點:
- 用戶只要只要知道具體的工廠類,就可以直接獲得產品對象,無須關心產品的創建過程
- 在系統需要增加新的產品的時候,只需要增加產品和具體的工廠類,無須修改原來的代碼。
缺點:
- 沒增加一個產品,就要增加產品類和對應的產品具體工廠類,增加了系統的復雜度。
三、抽象工廠模式
工廠方法類所生產的都是同一級別/種類的產品,但是在實際生活中可能會出現需要生產同一品牌的產品,如果使用工廠方法,就需要創建多個抽象工廠,具體工廠,我們為什么不將同一品牌的產品聚合起來,放在一個工廠里面,這樣可以滿足一個工廠生產出多級別的產品。
3.1 概念
1、抽象工廠模式是一種提供一個創建一組相關或相互依賴對象接口,且訪問類無需指定所要的產品的具體類就能訪問得到同族的不等級的產品的模式結構
2、抽象工廠實際上工廠方法模式的升級版,工廠方法模式只生產一個等級的產品,而抽象工廠可生產多個級別的產品。
3.2 結構
抽象工廠模式主要角色:
- 抽象工廠:提供創建產品的接口,它包含多個創建產品的方法,可以創建不同級別的產品。
- 具體工廠:實現抽象工廠,創建對應不同級別的產品,并返回。
- 抽象產品:定義了產品的規范,描述了產品主要特性和功能。
- 具體產品:實現抽象產品,并且由具體工廠來創建對象,與具體工廠是一對一的的關系。
3.3 實現
現在咖啡店,不僅要生產咖啡,還要生產甜點,假設生產的甜點是提拉米蘇、莫斯蛋糕,提拉秘書和屬于同一族,莫斯蛋糕和美式咖啡屬于同一族,我們就可以將同一族的兩個產品放到同一工廠里面。
- 抽象工廠
- 具體工廠
說明:
如果需要加一個產品族的話,只需要添加一個具體工廠實現抽象工廠即可,不需要修改其他類。
3.4 優缺點
優點:
當一個產品族中的多個對象被設計成一起工作時,它能保證客戶端始終只使用同一個產品族中的對象。
缺點:
當產品族中需要增加一個新的產品時,所有的工廠類都需要進行修改。
3.5 使用場景
- 當需要創建的對象是一系列相互關聯或相互依賴的產品族時,如電器工廠中的電視機、洗衣機、空調等。
- 系統中有多個產品族,但每次只使用其中的某一族產品。如有人只喜歡穿某一個品牌的衣服和鞋。
- 系統中提供了產品的類庫,且所有產品的接口相同,客戶端不依賴產品實例的創建細節和內部結構。
3.6模式擴展
3.6.1簡單工廠+配置文件解除耦合
可以通過工廠模式+配置文件的方式解除工廠對象和產品對象的耦合。在工廠類中加載配置文件中的全類名,并創建對象進行存儲,客戶端如果需要對象,直接進行獲取即可
- 抽象產品類和具體產品類
- bean.properties配置文件
- CoffeeFactory 工廠類
- 測試類Client
3.7JDK源碼解析-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()方法使用的是工廠模式;
四、 原型模式
4.1 概述
用一個已經創建的實例作為原型,來創建一個與原型對象相同的新對象
4.2 結構
原型模式包含如下角色:
- 抽象原型類: 規定具體原型對象必須實現的clone() 方法
- 具體原型類: 實現抽象圓形類的clone()方法。
- 訪問類: 使用具體原型類中的clone() 方法復制出新的對象
4.3 實現
原型模式分為淺克隆和深克隆
**淺克隆:**創建一個新的對象,新對象的屬性和原型對象的完全相同,對于非基本屬性類型,仍指向原來所指向的內存地址。
**深克隆:**創建一個新對象,新對象屬性中引用的其他對象會被克隆,不再指向原來的地址。
- RealizeType類: 具體事項類
- Client類: 測試訪問類
4.4 案例
一個公司中多個員工,采用其中一個員工作為原型類,通過原型模式創建多個員工
代碼如下:
/*** 員工類*/ public class Employee implements Cloneable{private String name;public String getName() {return name;}public void setName(String name) {this.name = name;}// 重寫clone方法@Overridepublic Employee clone() throws CloneNotSupportedException {return (Employee) super.clone();}// 編寫類方法public void work(){System.out.println(name + "正在上班...");} } // 測試類 public class Client {public static void main(String[] args) throws CloneNotSupportedException {Employee employee = new Employee();employee.setName("張三");Employee clone = employee.clone();clone.setName("李四");System.out.println(clone == employee);clone.work();employee.work();} } // 輸出如下 false // 兩者是不同的對象 李四正在上班... 張三正在上班...4.5 使用場景
- 對象的創建非常復雜,可以使用原型模式快捷的創建對象。
- 性能和安全要求比較高。
4.6 深克隆
深克隆是為了解決克隆的原型對象中存在引用類型的數據,克隆后新對象引用類型屬性仍然指向原來的地址,深拷貝可以它是新的地址
- 淺克隆引用類型屬性
- 深拷貝引用類型屬性
采用對象流來實現深克隆,只需修改測試類,和將原型對象序列化,引用類型數據序列化。
/*** 測試類*/ public class Client {public static void main(String[] args) throws CloneNotSupportedException, IOException, ClassNotFoundException {// 獲取原型對象Classes classes = new Classes();classes.setStu(new Student());classes.getStu().setName("張三");// 獲取輸出流對象,將原型對象寫入文件中ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("d:\\a.txt"));oos.writeObject(classes);oos.close();// 獲取輸入對象流,讀取創建新對象ObjectInputStream ooi = new ObjectInputStream(new FileInputStream("d:\\a.txt"));Classes clone = (Classes) ooi.readObject();clone.getStu().setName("李四");classes.getStu().study();clone.getStu().study();} }// 輸出結果如下 張三正在上課!!! 李四正在上課!!! // 可見兩個student沒有指向同一個地址五、建造者模式
5.1 概述
將一個復雜對象的構建與表示分離,使得同樣的構建過程可以創建不同的表示。
- 分離了部件的構造(由Builder來負責)和裝配(由Director負責),從而可以構造出復雜的對象。適用于:某個對象的構建過程非常復雜。
- 不同的構造器,相同的裝配,裝配值關注將不同的原件通過Buider創建,而裝配器將原件裝配起來
- 建造者模式可以將創建部件和裝配部件分開,一步一步創建出一個復雜的對象。
5.2 結構
建造者模式包含如下角色:
- 抽象創建者類(Builder): 這個接口實現復雜對象的部件創建規范,并不涉及到具體部件的創建
- **具體創建者類(ConcreateBuilder):**實現Builder接口方法,完成具體產品的創建,并且由指揮者類來調用具體創建者類的方法按照一定的順序來組裝
- **產品類(Product):**要創建的復雜對象
- 指揮者類(Director): 調用具體創建者類創建產品的各個部分,并且按照一定的順序將組件組裝起來,返回完整的對象產品
類圖圖下:
5.3 實例
假設要創建一輛汽車,是一個非常復雜的對象,我們只寫其中的兩個部件,輪子(Wheel) 和 椅子(Chair)兩個部件, 采用創建者方式。
- 代碼如下:
注意:
可以看出,指揮者類對于產品的創建有著至關重要的作用,Builder只是提供了部件的創建,而真正決定怎么創建的,需要由指揮者類(Director)來決定,當部件比較少的時候,可以將指揮者類合并到抽象創建者類里面
補充:
上訴代碼中,對于Car這產品也可以抽取出一個抽象類,讓具體類來實現的。可以將耦合度。
/*** 抽象創建者*/ public abstract class Builder {// 將car對象創建在抽象創建者中,實現類就可以對這個類進行創建部件Car car = new Car();abstract void setWheel();abstract void setChair();abstract Car createCar();public Car construct(){this.setWheel();this.setChair();Car car = this.createCar();return car;} }5.4 優缺點
優點:
- 建造者模式封裝型好,使用建造者模式可以有效的封裝變化,在使用的建造者模式的場景中,一般產品類和建造者類是比較穩定的,因此將業務邏輯封裝到指揮者類中對整體來說穩定性更高。
- 在建造者模式中,客戶端不必知道產品內部組成的細節,將產品本身與產品的創建過程解耦,使得相同的創建過程可以創建不同的產品對象。
- 可以更加精細地控制產品的創建過程 。將復雜產品的創建步驟分解在不同的方法中,使得創建過程更加清晰,也更方便使用程序來控制創建過程。
- 建造者模式很容易進行擴展,如果需要增加一個同一創建流程的產品,就只需要一個類來繼承Builder類,然后將具體創建者對象交給指揮者對象,就可以完成產品的創建。
缺點:
- 創建者模式要求添加的產品需要有很多的共同點,對應創建流程也需要大致相同,這樣的話才可以通過指揮者對象按照一定的流程來完成產品的創建。
5.5 使用場景
建造者(Builder)模式創建的是復雜對象,其產品的各個部分經常面臨著劇烈的變化,但將它們組合在一起的算法卻相對穩定,所以它通常在以下場合使用。
- 創建的對象較復雜,由多個部件構成,各部件面臨著復雜的變化,但構件間的建造順序是穩定的。
- 創建復雜對象的算法獨立于該對象的組成部分以及它們的裝配方式,即產品的構建過程和最終的表示是獨立的。
5.6 模式擴展
建造者模式還可以用來處理一個類的構造器傳入很多參數時,可讀性差,很容易記不住字段的順序造成字段賦值出錯的問題,可以采用的建造者模式來重構
重構前的代碼:
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{cpu='intel', screen='三星屏幕', memory='金士頓', mainboard='華碩'}采用創建者模式改進:
/*** 靜態內部創建者類改進后*/ public class Phone {private String cpu;private String screen;private String memory;private String mainboard;// 將構造方法私有化,采用創建者實現構建private Phone(Builder builder){this.cpu = builder.cpu;this.screen = builder.screen;this.memory = builder.memory;this.mainboard = builder.mainboard;}// 創建一個靜態內部創建者類public static class Builder{private String cpu;private String screen;private String memory;private String mainboard;// 分別創建屬性public Builder setCpu(String val){cpu =val;// return this 將 builder 返回,后面可以連寫return this;}public Builder setScreen(String val){screen = val;return this;}public Builder setMemory(String val){memory = val;return this;}public Builder setMainboard(String val){mainboard = val;return this;}// 外部類的構造方式已經私有了,所以通過內部類方法返回一個Phone對象public Phone build(){// 內部類可以直接調用外部類的私有構造器// 再將內部類這個對象傳給私有構造器,讓他來進行構造return new Phone(this);}}@Overridepublic String toString() {return "Builder{" +"cpu='" + cpu + '\'' +", screen='" + screen + '\'' +", memory='" + memory + '\'' +", mainboard='" + mainboard + '\'' +'}';} }// 測試類 public class Client {public static void main(String[] args) {// 通過改進后,我們就可以通過調用靜態內部類的方法,來實現構造器方法// 由于內部類每設置一個屬性就返回 Builder 所有可以連接賦值// 并且還可以選擇性的構造,不易造成錯誤Phone phone = new Phone.Builder().setCpu("Intel").setScreen("三星").setMemory("金士頓").setMainboard("華碩").build();System.out.println(phone);} }// 測試結果 Builder{cpu='Intel', screen='三星', memory='金士頓', mainboard='華碩'}5.7 創建者模式對比
5.7.1 工廠方法模式VS建造者模式
工廠方法模式注重的是整體對象的創建方式;而建造者模式注重的是部件構建的過程,意在通過一步一步地精確構造創建出一個復雜的對象。
我們舉個簡單例子來說明兩者的差異,如要制造一個超人,如果使用工廠方法模式,直接產生出來的就是一個力大無窮、能夠飛翔、內褲外穿的超人;而如果使用建造者模式,則需要組裝手、頭、腳、軀干等部分,然后再把內褲外穿,于是一個超人就誕生了。
5.7.2 抽象工廠模式VS建造者模式
抽象工廠模式實現對產品家族的創建,一個產品家族是這樣的一系列產品:具有不同分類維度的產品組合,采用抽象工廠模式則是不需要關心構建過程,只關心什么產品由什么工廠生產即可。
建造者模式則是要求按照指定的藍圖建造產品,它的主要目的是通過組裝零配件而產生一個新產品。
如果將抽象工廠模式看成汽車配件生產工廠,生產一個產品族的產品,那么建造者模式就是一個汽車組裝工廠,通過對部件的組裝可以返回一輛完整的汽車。
總結
以上是生活随笔為你收集整理的设计模式-创建者模式篇的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 合成器插件:KORG Software
- 下一篇: 对方启用和留言是什么意思_美国人老说“H