設計模式-挖掘工廠模式應用場景-全面分析工廠模式原理

原創 码农博士 2020-03-13 05:18

工廠模式的應用場景很多，到底再那些地方用過呢？爲什麼需要使用？有什麼好處？本文將從應用場景出發逐步揭開工廠模式背後的面紗。

先對工廠模式做一個大概的說明，其定義：

Define an interface for creating an object,but let subclasses decide which class to instantiate.Factory Method lets a class defer instantiation to subclasses.（定義一個用於創建對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。）

有了一個大概的概念後，我們來列舉一下其應用場景：

  • Spring獲取Bean，通過BeanFacotory工廠接口實現；
  • Log日誌，通過LoggerFactory獲取日誌對象；
  • jdbc，創建數據庫連接；

 Spring獲取bean的代碼如下：

# 通過xml獲取Bean
ApplicationContext ctx = new ClassPathXmlApplicationContext("bean-factoryMethod.xml");
DemoApplication bean = ctx.getBean(DemoApplication.class);

# 通過DI的方式注入Bean
@Autowired
DemoApplication demoApplication;

# 通過DI的方式注入Bean
@Service
DemoApplication demoApplication;

接下來我們看看ClassPathXmlApplicationContext是怎麼實現的，先看到下面的類結構圖：

BeanFactory接口存在四種工廠SimpleJndiBeanFactory、HierachicalBeanFacory、AutowireCapleBeanFactory、ListableBeanFactory，這四個工廠也對應了獲取Bean的不同方式比如通過Jndi獲取bean就使用SimpleJndiBeanFactory工廠，通過xml獲取bean就通過HierachicalBeanFacory工廠下的實現，通過依賴注入的方式就通過AutowireCapleBeanFactory工廠。

Spring中有一個最大的功能就是DI（依賴注入），所依賴的對象一般都是接口，這也吻合了設計原則中的依賴倒置原則（DIP），而創建bean與之相關的也都交給了Spring容器來管理，也就是不需要關注bean的創建過程以及與之相關的其他對象，也就是設計原則中的迪米特法則（LOD），在這裏我們所有的接口也可以使用其子類來進行替換，這也就吻合里氏替換原則（LSP）。

Spring創建bean的使用的設計模式即爲抽象工廠模式，需要實現不同創建bean方式只需要繼承BeanFactory接口進行實現。

抽象工廠定義：

抽象工廠模式（Abstract Factory Pattern）是圍繞一個超級工廠創建其他工廠。該超級工廠又稱爲其他工廠的工廠。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。

在抽象工廠模式中，接口是負責創建一個相關對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。

在最早學習Java的時候，JDBC獲取數據庫連接，實現代碼如下：


import java.sql.Connection;
import java.sql.SQLException;
 
public class ConnectionFactory {
 
	public static Connection getConnection() {
		Connection conn = null;
 
			try {
				conn = DataSourceHolder.getInstance().getDataSource()
						.getConnection();
			} catch (SQLException e) {
				e.printStackTrace();
			}
 
		return conn;
	}

}


import javax.sql.DataSource;
import org.apache.commons.dbcp.BasicDataSource;
 
 
public class DataSourceHolder {
	private BasicDataSource ds = new BasicDataSource();
 
	private DataSourceHolder() {
		ds.setDriverClassName("com.mysql.jdbc.Driver");
		ds.setUrl("jdbc:mysql://localhost:3306/dbo");//dbo爲連接的數據庫名稱
		ds.setUsername("root");//賬號
		ds.setPassword("root");//密碼
	}
	private static class SingletonHolder{
		private static DataSourceHolder instance = new DataSourceHolder();
	}
	public static DataSourceHolder getInstance(){
		return SingletonHolder.instance;
	}
	public DataSource getDataSource(){
		return ds;
	}

}

由於獲取數據連接需要比較多的參數設置，其過程還是相對比較複製，因此使用ConnectionFactory數據庫連接的工廠，非常簡單的就可以獲取數據庫連接對象（使用ConnectionFactory .getConnection()）。

以上這種使用靜態方法獲取數據庫連接的方式就是靜態工廠模式，看到這種方式是不是可以想到我們之前實現的很多代碼都非常相似，比如時間工具類、Json工具類，其實這些都歸納爲靜態工廠或者稱之爲簡單工廠。

簡單工廠模式(Simple Factory Pattern)：又稱爲靜態工廠方法(Static Factory Method)模式，它屬於類創建型模式。在簡單工廠模式中，可以根據參數的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。

接下來我們看看Logger的實現原理：

獲取logger的對象通常會通過以下方式獲取

org.slf4j.Logger logger = LoggerFactory.getLogger("DemoApplication");

查詢getLogger源碼：

public final class LoggerFactory {

    public static Logger getLogger(String name) {
        ILoggerFactory iLoggerFactory = getILoggerFactory();
        return iLoggerFactory.getLogger(name);
    }


    public static ILoggerFactory getILoggerFactory() {
        if (INITIALIZATION_STATE == UNINITIALIZED) {
            synchronized (LoggerFactory.class) {
                if (INITIALIZATION_STATE == UNINITIALIZED) {
                    INITIALIZATION_STATE = ONGOING_INITIALIZATION;
                    performInitialization();
                }
            }
        }
        switch (INITIALIZATION_STATE) {
        case SUCCESSFUL_INITIALIZATION:
            return StaticLoggerBinder.getSingleton().getLoggerFactory();
        case NOP_FALLBACK_INITIALIZATION:
            return NOP_FALLBACK_FACTORY;
        case FAILED_INITIALIZATION:
            throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG);
        case ONGOING_INITIALIZATION:
            // support re-entrant behavior.
            // See also http://jira.qos.ch/browse/SLF4J-97
            return SUBST_FACTORY;
        }
        throw new IllegalStateException("Unreachable code");
    }
}

很容易就可以判別出Logger使用了靜態工廠，我們可以看到getILoggerFactory()方法，在這裏根據logger不同配置參數創建了不同工廠，而這裏所有的工廠都是實現了ILoggerFactory接口，因此在日誌這個組件中也是用了抽象工廠，因此我們可以看出不管是Spring或者日誌組件都使用了抽象工廠來增強其擴展性，這也就體現了抽象工廠最大的特性就是可擴展性強，也吻合開閉原則對擴展開發對修改關閉。

接下來我們看看這樣的一段代碼：

產品 

public abstract class Product {      
     //產品類的公共方法
     public void method1(){
             //業務邏輯處理
     }  
     //抽象方法
     public abstract void method2();    
}

public class ConcreteProduct1 extends Product {
     public void method2() {
             //業務邏輯處理
     }
}

public class ConcreteProduct2 extends Product {
     public void method2() {
             //業務邏輯處理
     }
}

抽象工廠

public abstract class Creator {     
     /*
      * 創建一個產品對象，其輸入參數類型可以自行設置
      * 通常爲String、Enum、Class等，當然也可以爲空
      */        
     public abstract <T extends Product> T createProduct(Class<T> c);
}

public class ConcreteCreator extends Creator {      
     public <T extends Product> T createProduct(Class<T> c){
             Product product=null;
             try {
                    product = (Product)Class.forName(c.getName()).newInstance();
             } catch (Exception e) {
                    //異常處理
             }
             return (T)product;         
     }
}

場景類

public class Client {
     public static void main(String[] args) {
             Creator creator = new ConcreteCreator();
             Product product = creator.createProduct(ConcreteProduct1.class);
             /*
              * 繼續業務處理
              */
     }
}

以上是通過產品名稱創建對應的產品的過程，這也是很多資料中介紹工廠模式時所使用的示例，這也就時工廠方法模式最基本的實現。

總結：

（1）簡單工廠（Simple Factory）模式，又稱靜態工廠方法模式（Static Factory Method Pattern），一般使用靜態方法進行實現。
（2）工廠方法（Factory Method）模式，又稱多態性工廠（Polymorphic Factory）模式或虛擬構造子（Virtual Constructor）模式，Define an interface for creating an object,but let subclasses decide which class to instantiate.Factory Method lets a class defer instantiation to subclasses.（定義一個用於創建對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。）；
（3）抽象工廠（Abstract Factory）模式，Provide an interface for creating families of related or dependent objects without specifying their concrete classes.（爲創建一組相關或相互依賴的對象提供一個接口，而且無需指定它們的具體類。）。

優點：

  1. 首先，良好的封裝性，代碼結構清晰。一個對象創建是有條件約束的，如一個調用者需要一個具體的產品對象，只要知道這個產品的類名（或約束字符串）就可以了，不用知道創建對象的艱辛過程，降低模塊間的耦合。
  2. 其次，工廠方法模式的擴展性非常優秀。在增加產品類的情況下，只要適當地修改具體的工廠類或擴展一個工廠類，就可以完成“擁抱變化”。例如在我們的例子中，需要增加一個棕色人種，則只需要增加一個BrownHuman類，工廠類不用任何修改就可完成系統擴展。
  3. 再次，屏蔽產品類。這一特點非常重要，產品類的實現如何變化，調用者都不需要關心，它只需要關心產品的接口，只要接口保持不變，系統中的上層模塊就不要發生變化。因爲產品類的實例化工作是由工廠類負責的，一個產品對象具體由哪一個產品生成是由工廠類決定的。在數據庫開發中，大家應該能夠深刻體會到工廠方法模式的好處：如果使用JDBC連接數據庫，數據庫從MySQL切換到Oracle，需要改動的地方就是切換一下驅動名稱（前提條件是SQL語句是標準語句），其他的都不需要修改，這是工廠方法模式靈活性的一個直接案例。
  4. 最後，工廠方法模式是典型的解耦框架。高層模塊值需要知道產品的抽象類，其他的實現類都不用關心，符合迪米特法則，我不需要的就不要去交流；也符合依賴倒置原則，只依賴產品類的抽象；當然也符合里氏替換原則，使用產品子類替換產品父類，沒問題！

使用場景：

  1. 首先，工廠方法模式是new一個對象的替代品，所以在所有需要生成對象的地方都可以使用，但是需要慎重地考慮是否要增加一個工廠類進行管理，增加代碼的複雜度。
  2. 其次，需要靈活的、可擴展的框架時，可以考慮採用工廠方法模式。萬物皆對象，那萬物也就皆產品類，例如需要設計一個連接郵件服務器的框架，有三種網絡協議可供選擇：POP3、IMAP、HTTP，我們就可以把這三種連接方法作爲產品類，定義一個接口如IConnectMail，然後定義對郵件的操作方法，用不同的方法實現三個具體的產品類（也就是連接方式）再定義一個工廠方法，按照不同的傳入條件，選擇不同的連接方式。如此設計，可以做到完美的擴展，如某些郵件服務器提供了WebService接口，很好，我們只要增加一個產品類就可以了。
  3. 再次，工廠方法模式可以用在異構項目中，例如通過WebService與一個非Java的項目交互，雖然WebService號稱是可以做到異構系統的同構化，但是在實際的開發中，還是會碰到很多問題，如類型問題、WSDL文件的支持問題，等等。從WSDL中產生的對象都認爲是一個產品，然後由一個具體的工廠類進行管理，減少與外圍系統的耦合。
  4. 最後，可以使用在測試驅動開發的框架下。例如，測試一個類A，就需要把與類A有關聯關係的類B也同時產生出來，我們可以使用工廠方法模式把類B虛擬出來，避免類A與類B的耦合。目前由於JMock和EasyMock的誕生，該使用場景已經弱化了，讀者可以在遇到此種情況時直接考慮使用JMock或EasyMock。

筆者的微信公衆號，每天一篇好文章：

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

設計模式-深入單例模式精髓-剖析單例模式適用場景以及多線程問題

码农博士 2020-03-11 18:46:44

設計模式-深入單例模式精髓-剖析單例模式適用場景以及多線程問題

码农博士 2020-03-11 18:46:44