從封裝變化的角度看設計模式——對象創建

来源:https://www.cnblogs.com/yychuyu/archive/2020/07/10/13281010.html
-Advertisement-
Play Games

封裝變化之對象創建 在對象創建的過程中，經常會出現的一個問題就是通過顯示地指定一個類來創建對象，從而導致緊耦合。這是因為創建對象時指定類名將使你受特定實現的約束而不是特定介面的約束。這會使未來的變化更加複雜。要避免這種情況，就應該間接地創建對象。 這種緊耦合的問題很大程度是由new關鍵字帶來的，由於 ...


封裝變化之對象創建

在對象創建的過程中，經常會出現的一個問題就是通過顯示地指定一個類來創建對象，從而導致緊耦合。這是因為創建對象時指定類名將使你受特定實現的約束而不是特定介面的約束。這會使未來的變化更加複雜。要避免這種情況，就應該間接地創建對象。

這種緊耦合的問題很大程度是由new關鍵字帶來的，由於new的緊耦合出現，使得緊耦合的類很難獨立地被覆用，因為它們之間是相互依賴的。並且緊耦合產生單塊的系統，要改變或者刪掉一個類，就必須要理解和改變其他許多類。這也是導致系統難以維護和移植的一個重要原因。

所以可以通過“對象創建”模式繞開new，從而避免在對象創建（new）過程中所導致的緊耦合（依賴具體的類），以此支持對象創建的穩定。

那麼如何避免new呢？舉個例子！

	public void fun1(){
		//...
		Product p = new Product(); //改為：Product p = productFactory.createProduct();
		//...
	}

這樣的方式就是通過一個工廠調用一個方法來創建相應的產品，但是可能大家又會產生一個問題，這樣操作雖然解決了Product的new操作，但是對於ProductFactory而言不是也需要通過new來產生嗎？

對於這個問題，我想是很多人在接觸到設計模式的時候都會去思考的問題，既然ProductFactory還是要用到new，那工廠類還有存在的必要嗎？這時，我們可以會想到兩種解決方式，一是將createProdyct()方法寫成靜態方法，這樣調用的時候自然不需要new了。二是通過註入的方式，比如在應用類當中通過setter或是構造方法傳入一個工廠類的對象。

對於靜態方法而言，簡單地說，即使是使用靜態方法，那Product p = ProductFactory.createProduct()這樣依然是一種緊耦合的方式，因為工廠類無法替換，和直接new出產品區別不大。

對於註入方式，大家更多的是疑惑，既然可以傳入一個工廠類對象，那為什麼不直接傳入相應的產品，不是更簡單直接嗎？當然不是的，首先需要明白的是，工廠類的作用是作為一個籠子，這個籠子需要幫助我們束縛住 ‘未來的變化’ ，要知道一個產品的變化可能總是大於工廠的變化。在這種情況下，舉出一個最簡單的例子，你在編碼的過程中，可能會用到不只一個產品，那你就可能需要很多setter或者修改構造方法；但是如果這些產品都可以通過這個工廠來獲取，是不是就相當於用籠子關住了變化，使其在一個範圍中跳動。

在學習設計模式時，永遠要記住的一句話就是“設計模式是用來教會我們如何應對未來可能的變化”。如果你能夠確定自己的系統未來沒有變化，那自然用不到設計模式；或者你的系統未來全是變化，那也用不到設計模式，設計模式做的就是隔離穩定與變化，如果沒有穩定，那就用不到設計模式。

‘new’是一種硬編碼，究竟 ’硬‘ 在那裡，同樣一個簡單的理由，如果未來構造方法發生變化或者說構造參數增加（減少），而在源碼中有很多地方都是通過new來獲取實例對象，找到並修改源碼將會是一項很大的工作。

在解決這樣的 “對象創建” 問題中就有工廠方法、抽象工廠、原型模式和建造者模式等相關設計模式。

工廠方法（Factory Method)

  1. 意圖

    定義一個用於創建對象的介面，讓子類決定實例化哪一個類。FactoryMethod使得一個類的實例化延遲到其子類。

  2. 實例

    Factory Method相對於簡單工廠而言，完全遵循了“不改代碼”的原則，但是其使用情形相比抽象工廠使用條件沒有那麼高，因此可以說是使用最多的創建型模式之一了。

    考慮這樣一個應用，它可以向用戶顯示多種文檔，比如word、pdf、txt等等。在這個框架中，首先，想到的可能就是應用簡單工廠模式。

    public interface Document{
    public void open();
    public void close();
    public void save();
   // ......
}
public class PdfDocument implements Document{
    @Override
    public void open(){
        //open pdfDocument code
        System.out.println("open pdf!");
    }

    @Override
    public void close() {
        System.out.println("close pdf!");
    }

    @Override
    public void save() {
        System.out.println("save pdf!");
    }
   // ......
}
public class TxtDocument implements Document{
    //Txt實現代碼,同PdfDocument
    ......
}
public class DocumentFactory{
    public Document createDocument(String type){
        if(type=="pdf"){
           
            return new PdfDocument();
        }else if(type=="txt"){
            return new TxtDocument();
        }else {
            return null;
        }
    }
}

    //簡單工廠模式在客戶類當中的調用
public class Client {
    public static void main(String[] args) {
        DocumentFactory factory
            = new DocumentFactory();
        Document pdfDocument 
 			= factory.createDocument("pdf");
        pdfDocument.open();
        pdfDocument.save();
        pdfDocument.close();

        Document txtDocument 
  			= factory.createDocument("txt");
        txtDocument.open();
        txtDocument.save();
        txtDocument.close();
    }
}

    這樣簡單工廠模式，在不考慮未來新文檔類型的情況下，確實是一種不錯的實現方法。但是在後續的擴展過程當中，如果需要增加新的文檔類，就需要去修改DocumentFactory中的createDocument()方法，增加新的類別，並且客戶還必須知道這些類別才能使用。

    為了應對這種情況，就出現了工廠方法。工廠方法就直接將工廠抽象出來，每個產品對應一個工廠，消除工廠模式中的條件分支結構（其實還有一種消除條件語句的模式，就是之前“組件協作”當中的策略模式）。

    //Document部分不變
public interface Document{
    public void open();
    public void close();
    public void save();
    ......
}
public class PdfDocument implements Document{
    public void open(){
        //open pdfDocument code
    }
    // close 和 save
    ......
}
public class TxtDocument implements Document{
    //Txt實現代碼
    ......
}
//並且後續可以擴展新的文檔類
......

    //修改factory部分如下
public interface DocumentFactory{
    public Document createDocument();
}
public class PdfDocumentFactory 
    		implements DocumentFactory {
    @Override
    public Document createDocument() {
        return new PdfDocument();
    }
}
public class TxtDocumentFactory 
    		implements DocumentFactory {
    @Override
    public Document createDocument() {
        return new TxtDocument();
    }
}
//如果後續有新的產品，直接再實現DocumentFactory,得到新的工廠
......

    //調用過程可做如下修改：
public class Client {
    public static void main(String[] args) {
        //利用多態性質，直接生成相應的factory子類
        //消除了控制耦合
        DocumentFactory factory = new PdfDocumentFactory();
        Document pdfDocument
                = factory.createDocument();
        pdfDocument.open();
        pdfDocument.save();
        pdfDocument.close();

        factory = new TxtDocumentFactory();
        Document txtDocument
                = factory.createDocument();
        txtDocument.open();
        txtDocument.save();
        txtDocument.close();
    }
}

    有人可能會有疑問，這樣不是還沒完全消除new嗎？首先這裡的客戶類已經到最高的調用層次了，這個過程當中是必然會有new的出現，不然怎樣進行程式調用呢？

    我們所說的消除new的過程是指main與factory之間，產生的一個中間層次（如下麵的App）中去消除new。

    //這樣的代碼中，就消除了new的存在
//具體的註入過程可以由其他的形式完成，比如Spring中的DI
public class App{
   private DocumentFactory factory;
    public void setFactory(DocumentFactory factory) {
        this.factory = factory;
    }
    public void operateDoc(){
       Document document = factory.createDocument();
       document.open();
       document.save();
       document.close();
   }
}
//main中的代碼是最高層次，也是變化最頻繁的層次，這裡是不可能消除new的
public class Client {
    public static void main(String[] args) {
        DocumentFactory factory = new PdfDocumentFactory();
        App app = new App();
        app.setFactory(factory);
        app.operateDoc();
        //同樣對於其他的工廠類也是可以採用同樣的方式調用。
        ......
    }
}

    這樣修改代碼的好處在那裡呢？第一，顯而易見的就是完全實現了“開閉原則”的思想，擴展時不再需要去修改源碼。第二，有些對象的創建過程可能比較複雜，因此如果直接在應用程式當中使用new或者其他形式創建很麻煩，通過工廠創建之後，就不再需要去關註那些複雜的創建過程。第三，通過new創建，始終是一種硬編碼的形式，如果在應用程式當中過多的使用這種方式，那麼一旦某對象的創建方式發生改變，修改源碼必然是很繁瑣的。

  3. 結構——類創建型模式

    FactoryMethod .png

  4. 參與者

    • Product（Document）

    定義工廠方法中工廠創建的對象的介面。

    • ConcreteProduct（PdfDocument、TxtDocument）

      實現Product的介面。

    • Creator（DocumentFactory）

      聲明工廠方法——createProduct()，可以調用該方法返回一個Product類型的對象。

    • ConcreteCreator（PdfDocumentFactory、TxtDocumentFactory）

      重定義工廠方法以返回具體的ConcreteProduct。

    • Client（客戶類）

      使用工廠和產品，工廠方法模式中，客戶類也是一個重要的參與者，因為工廠方法主要的作用就是分離開客戶類與產品類之間的耦合關係，所以脫離客戶類去談工廠方法模式時，總會覺得差了些什麼東西，無法完全體會到工廠方法模式的優勢。

  5. 適用性

    在下列情況下可以使用Factory Method模式：

    • 當一個類不知道它所必須創建的對象的類的時候。
    • 當一個類希望由它的子類來指定它所創建的對象的時候。
    • 當類將創建對象的職責委托給多個幫助子類中的某一個，並且你希望將哪一個幫助子類是代理者這一信息局部化的時候。

    簡單地說，就是使用過程中只需要聲明一個抽象工廠類的引用，具體調用那個工廠去生成那個對象，是由調用者去確定的。

  6. 相關模式

    Abstract Factory經常用工廠方法來實現，抽象工廠創建產品的過程就可以使用工廠方法來完成。

    工廠方法通常在Template Method中被調用，這一點在“組件協作”當中也提到過。

  7. 思考

    • Creator的兩種實現情況。第一種情況，Creator只作為抽象層，也就是只聲明介面，不做任何的實現；這種情況就必須要子類來實現。第二種情況，Creator作為一個具體的實現類，而不是抽象類，這種情況下，Creator可以提供一個預設的實現介面，這樣即使沒有子類重寫它，客戶可以通過這樣一個預設的實現完成任務。
    • 靈活運用工廠方法模式。作為一種創建類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要註意的地方就是複雜對象適合使用工廠方法模式，而簡單對象，特別是只需要通過 new 就可以完成創建的對象（這也是為什麼工廠方法講解用到的例子總是無法說服人的原因之一），無需使用工廠方法模式；因為使用工廠方法模式，就需要引入一個工廠類，會增加系統的複雜度。

抽象工廠(Abstract Factory)

  1. 意圖

    提供一個創建一系列相關或相互依賴對象的介面，而無需指定他們具體的類。

  2. 實例

    假定存在這樣一個服務層，該層當中需要做的就是訪問資料庫中的數據，並且執行一系列的相關操作。根據面向介面編程的思想，可以先作這樣一個代碼編寫。

    //對資料庫進行訪問的三個介面
//先建立連接，再執行相關操作，最後返回相應結果
public interface DBConnection{}
public interface DBCommand{}
public interface DBDataReader{}

//對於MySql，可以建立以下實現
public class MySqlDBConnection implements DBConnection{}
public class MySqlDBCommand implements DBCommand{}
public class MySqlDBDataReader implements DBDataReader{}
//同樣對於Sql Server，Oricle也是這樣的實現
......

    這樣的實現下，我們可以說是滿足了面向介面編程的一個思想；並且在實現中，我們可以為每個介面，按照工廠方法模式，為其創建一個工廠。

    //工廠介面
public interface DBConnectionFactory{
    public DBConnection createDBConnetion();
}
public interface DBCommandFactory{
     public DBCommand createDBCommand();
}
public interface DBDataReaderFactory{
    public DBDataReader createDBDataReader();
}
//然後對於每個具體的資料庫，實現不同的具體工廠
//以MySql為例
public class MySqlDBConnetionFactory implements DBConnectionFactory {
    @Override
    public DBConnection createDBConnetion() {
        return new MySqlDBConnection();
    }
}
public class MySqlDBCommandFactory implements DBCommandFactory {
    @Override
    public DBDBCommand createDBCommand() {
        return new MySqlDBCommand();
    }
}
public class MySqlDataReaderFactory implements DataReaderFactory {
    @Override
    public DBDataReader createDataReader() {
        return new MySqlDataReader();
    }
}
//剩下的Orcle,Sql Server也是如此
......

    工廠模式方法的調用就不再演示，區別和工廠方法中的Document例子中差別不大。

    對於這樣的實現，雖然我們很好的利用了工廠方法模式，但是也引入了工廠方法模式的一個弊端——大量的對象和類（本例當中，三個系列，每個系列三個產品，光產品就是9個子類；每個產品再對應一個工廠，一共就是18個子類）。在使用的過程中，反而能夠明顯的感覺到系統複雜度不減反增。並且，DBConnection、DBCommand和DBDataReader明顯是有著一定的關係的，換句話說，MySql建立的DBConnection是和MySqlDBCommand、MySqlDBDataReader一起使用的，如果出現MySqlDBConnection、OricleDBCommand、SqlServerDBDataReader這種組合肯定是無法正常執行的。這時抽象工廠的出現，就很好的解決了這樣的問題。

    //首先，具體的產品類不會發生變化，簡化的主要是工廠層次
//先抽象出抽象工廠，將產品系列的創建方法合併到一個介面中
public interface DBFactory{
    public DBConnection createDBConnetion();
    public DBCommand createDBCommand();
    public DBDataReader createDBDataReader();
}
//根據不同的具體工廠，創建具體的對象
public class MySqlDBFactory implements DBFactory {
    @Override
    public DBConnection createDBConnetion() {
        
        return new MySqlDBConnection();
    }

    @Override
    public DBCommand createDBCommand() {
        return new MySqlDBCommand();
    }

    @Override
    public DBDataReader createDBDataReader() {
        return new MySqlDBDataReader();
    }
}
//Oricle,sql server的工廠，同樣如此
......

    抽象工廠主要是對工廠層次的簡化，這樣修改下來，對比工廠方法模式，減少了2/3的工廠子類創建，只需要3個工廠（有多少個產品系列就有多少個工廠子類）就可以完成產品的創建。

    這樣的一種創建工廠方式，不僅減少了工廠的數量，而且使得產品的一致性得以保證，它可以保證，一次只能使用同一個系列當中的對象。

    public class Client {
    public static void main(String[] args) {
        DBFactory factory = new MySqlDBFactory();
        App app = new App();
        app.setFactory(factory);
        app.operate();
        //同樣對於其他的工廠類也是可以採用同樣的方式調用。
        // ......
    }
}
class App{
    private DBFactory factory;
    public void setFactory(DBFactory factory) {
        this.factory = factory;
    }
    public void operate(){
        DBConnection connection
                = factory.createDBConnetion();
        DBCommand command 
            	= factory.createDBCommand();
        DBDataReader reader 
            	= factory.createDBDataReader();
        //執行相關操作
        .....
    }
}

    這樣的應用程式代碼，在一定程度上就減少了工廠子類的數量，並且在operate()中保證了產品系列的一致性，使得MysqlDBFactory生成的產品，只會是與MySql相關的。

  3. 結構——對象創建型模式

    Abstract Factory.png

  4. 參與者

    • AbstractFactory（DBFactory）

      聲明一個創建抽象產品對象的操作介面。

    • ConcreteFactory（MySqlDBFactory）

      實現創建具體產品對象的操作。

    • AbstractProduct（DBConnection、DBCommand、DBDataReader）

      為一類產品對象聲明一個介面。

    • ConcreteProduct（MySqlDBConection、MySqlDBCommand、MySqlDBDataReader）

      定義一個將被相應的具體工廠創建的產品對象，並實現抽象產品的相應介面。

    • Client

      調用抽象工廠和抽象產品提供的介面。在創建者模式當中，客戶類也是重要的參與成員，因為對創建模式的理解容易混亂的點正是在客戶類中的調用過程 （new） 產生的，關於這個問題，已經在前面做過很多解釋了，不再多說。

  5. 適用性

    以下情況可以使用AbstractFactory模式：

    • 一個系統要獨立於它的產品的創建、組合和表示時。
    • 一個系統要由多個產品系列中的一個來配置時。
    • 當你要強調一系列相關的產品對象的設計以便進行聯合使用時。
    • 當你提供一個產品類庫，而只想顯示它們的介面而非實現時。

  6. 相關模式

    Singleton：一個具體的工廠通常會是一個單件。因為在一個應用中，一般每個產品系列只需要一個具體工廠。

    Factory Method：在Abstract Factory中，僅僅是聲明一個創建對象的介面，真正的創建過程是由具體工廠實現的。這時，可以為每一個方法對應的具體對象之間再定義一個工廠方法。但其問題就在於，這樣的做法就像是在工廠方法上再套上一層抽象工廠，從而又增加了系統的複雜度。

  7. 思考

    • 難以支持新種類的產品 對於工廠模式而言，它的最大優點就在於保證了產品的一致性，但也正是如此，這就使得它的產品系列需要保持穩定，如果在後續的過程中出現新的產品，比如在實例當中需要增加一個新的功能系列，就需要去擴展DBFactory介面，並且涉及到DBFactory及其子類的改變。
    • 定義可擴展的工廠 這是對於新種類產品創建靈活性的提高，但是不太安全；就是給創建 對象的操作增加一個參數，該參數來指定將被創建的對象種類。使用這種方式，抽象工廠就只需要一個“Create”方法和一個標識符參數即可完成創建操作。但問題就在於，客戶需要完全瞭解所有的參數才能更好使用工廠創建自己所需要的對象。

原型模式（Prototype）

  1. 意圖

    用原型實例指定對象的創建種類，並且通過拷貝這些原型創建新的對象。

  2. 實例

    Prototype模式，有點像是對工廠方法模式中產品與工廠的合併。怎麼說呢?看下麵的代碼：

    //工廠方法模式中的產品類與工廠方法類
public interface Document{
    public void open();
    public void close();
    public void save();
    ......
}
public interface DocumentFactory{
    public Document createDocument();
}

    這是在Factory Method中使用的創建方式，而原型做的事就是，不再用工廠來進行創建，而是轉而克隆的方式。變成下麵這樣：

    //合併Document和DocumentFactory
public abstract class Document 
    			implements Cloneable{
    public void open();
    public void close();
    public void save();
    ......
    //相當於Factory中的createDocument();
   public Object clone() {
      Object clone = null;
      try {
         clone = super.clone();
      } catch (CloneNotSupportedException e) {
         e.printStackTrace();
      }
      return clone;
   }
}
public class PdfDocument implements Document{
    @Override
    public void open(){
        //open pdfDocument code
        System.out.println("open pdf!");
    }
    @Override
    public void close() {
        System.out.println("close pdf!");
    }
    @Override
    public void save() {
        System.out.println("save pdf!");
    }
    //......
}
//文檔類的實現與工廠方法中的一樣
......

    那麼在具體的客戶類當中就是通過這樣一種方式來進行調用：

    public class App{
    //在工廠方法模式當中，這裡是documentFactory
	private Document prototype;
    public void setDoucument(Document document){
        prototype = document;
    }
    public void useDocument(){
        //documentFactory.createDocument();
        Document doc = prototype.clone();
        //然後使用prototype克隆出來的doc進行操作
        doc.open();
        ......
    }
}
//在客戶類中調用表現
public class Client {
    public static void main(String[] args) {
        Document doc = new PdfDocument();
        App app = new App();
        app.setFactory(doc);
        app.useDocument();
        //同樣對於其他的工廠類也是可以採用同樣的方式調用。
        //......
    }
}

    問題來了，為什麼不直接用原型（prototype），而是要多一步克隆？解決這個問題，首先要明白的是，我們使用原型的目的不是將原型作為客戶類的一個屬性去使用，而是一個創建者。既然是一個創建者，那麼在使用的過程中，就不只一個地方會用到同樣類型的對象；如果在不同的地方都直接使用原型，可能會在某個地方修改了原型的值，從而使得其他直接使用原型的方法出現不可預知的錯誤。

  3. 結構——對象創建型模式

    Prototype.png

  4. 參與者

    • Prototype（Document）

      聲明一個克隆自身的介面。

    • ConcretePrototype（PdfDocument...）

      繼承Prototype並實現克隆自身的介面。

    • Client

      讓一個原型克隆自身從而創建一個新的對象。

  5. 適用性

    • 當一個系統應該獨立於它的產品創建、構成和表示時，可以使用Prototype模式。

    • 當要實例化的類是在運行時候指定時，比如動態裝載。

    • 為了避免創建一個產品類平行的工廠類層次時。

    • 當一個類的實例只能有幾種不同狀態組合中的一種時，建立相應數目的原型並克隆他們可以比每次用合適的狀態手工實例化該類更方便一些。

  6. 相關模式

    Abstract Factory和Prototype在某種方面是相互競爭的，但是在某種情況下也是可以一起使用，比如，在抽象工廠中存儲一個被克隆的產品集合，在使用時，直接根據集合中的對象返回相應的產品。

    大量使用Composite（組合模式）和Decorator（裝飾器模式）的設計上也可以採用Protorype來減少Composite或Decorator對象的創建。

  7. 思考

    • 減少了子類的構造。實例當中就可以看出，原型模式簡化了工廠方法模式中的工廠類，因此，減少了許多子類的創建。
    • 資源優化。類初始化可能需要消化非常多的資源，這個資源包括數據、硬體資源等等，使用原型模式就可以減少這樣一個初始化過程。
    • 深、淺拷貝的問題。對於java而言，淺拷貝實現 Cloneable，深拷貝是通過實現 Serializable 讀取二進位流。

建造者模式( Builder)

  1. 意圖

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

  2. 實例

    在游戲場景當中，尤其是3d場景中，必不可少就是建築物，比如說房子。對房子的構建肯定不是一下全部構建完成的，而是會分成幾個部分，比如牆、窗戶、地板、房頂、門，一部分、一部分地去構建。

    public abstract class House{
    //房子屬性，紋理、材質...
    private Texture texture;
    private Material material;
    ......
    //牆、窗戶、地板、房頂、門
    public Wall buildWall();
    public Window buildWindow();
    public Floor buildFloor();
    public Door buildDoor();
    public Roof buildRoof();
    //房子構建過程
    public void buildHouse(){
        buildFloor();
        Wall[] walls = new Wall[4];
        for(int i=0;i<walls.length;i++)
            walls[i] = buildWall();
        Window window = buildWindow();
        wall[1].setWindow(window);
        Door door = builDoor();
        wall[2].setDoor(door);
        buildRoof();
    }
}

    這種構建方式，採用的明顯就是模板方法（Template Method），這種實現方式還可以根據不同的房子類型，實現具體的細節。

    //石頭屋
public class StoneHouse extends House{
    //具體實現細節
    .......
}
//茅草屋
public class ThatchedHouse extends House{
    //具體實現細節
    .......
}

    //按照模板主方法在客戶類中的調用形式表現：
public class Client{
    public static void main(String[] args){
        //只需要生成一個相應對象即可在游戲場景中完成相應類型房子的創建
        House house = new StoneHouse();
        house.buildHouse();	//生成石頭屋
        
        house = new ThatchedHouse();
        house.buildHouse();	//生成茅草屋
        
    }
}

    這種實現有什麼問題呢？類太臃腫了，對吧~這樣的實現過程，可以體現復用的思想，但是問題之一就在於所有的內容全部都放在了一個類中，體現不出單一職責和類的信息與行為集中；這時就可以將創建過程分離出來，形成一個Builder，由這樣一個Builder來專門負責創建。

    //Director
public class House{
    //房子屬性，紋理、材質...
    private Texture texture;
    private Material material;
    ......
    //增加builder的引入
    private HouseBuilder houseBuilder;
    public void setHouseBuilder(HouseBuilder hBuilder){
        houseBuilder = hbuilder;
    }
    //房子構建過程
    public void buildHouse(){
        houseBuilder.buildFloor();
        Wall[] walls = new Wall[4];
        for(int i=0;i<walls.length;i++)
            walls[i] = houseBuilder.buildWall();
        Window window 
            = houseBuilder.buildWindow();
        wall[1].setWindow(window);
        Door door = houseBuilder.builDoor();
        wall[2].setDoor(door);
        houseBuilder.buildRoof();
    }
}

//分離出來的builder
public interface HouseBuilder{
    //牆、窗戶、地板、房頂、門
    public Wall buildWall();
    public Window buildWindow();
    public Floor buildFloor();
    public Door buildDoor();
    public Roof buildRoof();
}
public class StoneHouseBuilder
    			implements HouseBuilder{
    //具體實現細節
    .......
}
public class ThatchedHouseBuilder 
    			implements HouseBuilder{
    //具體實現細節
    .......
}

    //修改過後，在客戶類中的調用形式表現：
public class Client{
    public static void main(String[] args){
        //只需要生成一個相應對象即可在游戲場景中完成相應類型房子的創建
        House house = new House();
        HouseBuilder builder 
            	= new StoneHouseBuilder();
        house.setHouseBuilder(builder);
        house.buildHouse();
        
        builder = new ThatchedHouseBuilder();
        //這個set過程可以運行時完成
        house.setHouseBuilder(builder);
        house.buildHouse();
    }
}

    通過這樣一種方式，實現複雜對象構建與表示的分離，並且，對於不同的房子對象，如果房子其他參數沒有任何差別，就只需要傳入相應的builder即可，而不需要再生成各種各樣的子類（如StoneHouse、ThatchedHouse）。

    一旦生成對象，只需要修改其builder就可以馬上改變其對象表示，而不需要新生成對象。並且這種修改過程，是可以動態完成的，就如果Spring當中的依賴註入過程一樣，可以在運行時刻完成，而不一定是一開始就確定的

  3. 結構——對象創建型模式

    Builder.png

  4. 參與者

    • Builder（HouseBuilder）

      為創建一個Product對象的各個部件指定抽象介面。

    • ConcreteBuilder（StoneHouseBuilder、ThatchedHouseBuilder）

      • 實現Builder的介面以構造各裝配該產品的各個部件。
      • 定義並明確它所創建的表示。

    • Director（House）

      構造一個使用builder的對象。

    • Product（Wall、Window...）

      包含了定義組成部件的類以及被構造的複雜對象等。

  5. 適用性

    Builder的適用情況：

    • 當創建複雜對象的演算法應該獨立於該對象的組成部分，以及它們的裝配方式時。
    • 當構造過程必須允許被構造的對象的不同的表示時。

    Builder模式更多的是體現的一種思想，而不是具體的過程，這種思想就是，當一個類的信息與行為過於臃腫時，也許可以採用Builder這種方式對類的信息與行為進行重新劃分，從而使得類看起來更加的“輕” 。

  6. 相關模式

    Abstract Factory和Builder都是對複雜對象的創建封裝，但二者的區別在於，Builder著重於一步一步構建一個複雜對象，而Abstract Factory著重於多個系列產品對象的創建，並且系列對象之間有著某種聯繫。

    Composite模式中對象通常情況下就是用Builder生成的。

  7. 思考

    • 可以改變產品的內部表示 Builder對象提供給Director一個構造產品對象的內部介面，從而使得產品的表示和內部結構得以隱藏。因此，在構建過程中，只需要替換不同的Builder就可以得到不同的表示。
    • Builder中的方法可以預設為空 這樣在具體的實現過程中，客戶可以只實現他們感興趣的操作，這種方式其實在很多模式中都可以應用，其最主要的思想就是能用預設配置當然是最好的。

公眾號：良許Linux

有收穫？希望老鐵們來個三連擊，給更多的人看到這篇文章


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 基於.NetCore3.1系列 —— 認證授權方案之授權揭秘 (下篇)
    一、前言 回顧：基於.NetCore3.1系列 —— 認證授權方案之授權揭秘 (上篇) 在上一篇中，主要講解了授權在配置方面的源碼，從添加授權配置開始，我們引入了需要的授權配置選項，而不同的授權要求構建不同的策略方式，從而實現一種自己滿意的授權需求配置要求。 在這一節中，繼續上一篇的內容往下深入瞭解 ...
  • 每日預約送貨/提貨時間配置一鍵生成
    一、原因 用戶希望後臺維護每日預約送貨/提貨時間配置一鍵生成，不需要過多操作。 二、整理實現思路 1.靈活維護/配置送貨、提貨時間段及允許預約數量的模板，如圖所示： 2.預約日期處理： ① 查找提貨/送貨時間配置的預約日期中最新一條數據大於等於當天日期，則預約日期自增一天； ② 查找提貨/送貨時間配 ...
  • C#中關於Task.Yeild()的探究
    在與同事討論async/await內部實現的時候，突然想到Task.Yeild()這個函數，為什麼呢，瞭解一點C#async/await內部機制的都知道，在await一個非同步任務（函數）的時候，它會先判斷該Task是否已經完成，如果已經完成，則繼續執行下去，不會返回到調用方，原因是儘量避免線程切換， ...
  • WindowsForm如何移動一個沒有標題欄的視窗
    在WinForm程式中，要移動沒有標題欄的視窗，基本的實現思路是監聽需要拖動視窗內的控制項的滑鼠事件，然後將滑鼠位置發送給視窗進行相應的位移就可以了。通過借用Windows API也可以很容易實現這一點，比如像下麵這樣。 public class Win32Api { public const int ...
  • (一)學習瞭解OrchardCore筆記——開篇：基於asp.net core的OrchardCore
    想深入瞭解OrchadCore源碼許久了，但是讀源碼的時候遇到很多問題而網上的參考資料太少了(幾乎都是OrchadCms不帶OrchardCore的)，現在解決得差不多了，做下筆記方便自己查看，有錯誤之處也請大家幫忙指出，謝謝。 OrchardCore是一個基於asp.net core的cms(廢話 ...
  • ASP.NET中使用一般處理程式ashx作為後臺處理實現響應get和post請求
    場景 ASP.NET中新建Web網站並部署到IIS上(詳細圖文教程)： https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/107199747 在上面博客中已經將網站部署到了IIS上。 怎樣對前端的請求進行響應普通文本和JSON數據以及 ...
  • 【asp.net core 系列】15 自定義Identity
    0. 前言 在之前的文章中簡單介紹了一下asp.net core中的Identity，這篇文章將繼續針對Identity進行進一步的展開。 1. 給Identity添加額外的信息 在《【asp.net core 系列】13 Identity 身份驗證入門》一文中，我們大概瞭解瞭如何使用Identit ...
  • .Net Core微服務入門全紀錄（八）——Docker Compose與容器網路
    Tips：本篇已加入系列文章閱讀目錄，可點擊查看更多相關文章。 前言 上一篇【.Net Core微服務入門全紀錄（七）——IdentityServer4-授權認證】中使用IdentityServer4完成了鑒權中心的搭建，配合網關實現了統一的授權認證。進行到這裡，系統環境已經比較複雜了，想把整個系統 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類