設計模式——從接口的角度切入靜態工廠模式

面向接口編程

接口的定義及功能

這裏從java介入吧，在java中，接口是一種特殊的類，接口裏面的量都是常量，接口的方法只有定義而沒有實現，換句話說，接口就像一個菜單，它只會告知你我有什麼菜，而並不會有實際的菜品，因此一般用接口來定義實現類的外觀，根據外部應用所須要的功能，約定實現類的能力（類的功能不只限於接口約束）。經過接口，能夠實現不相關類的相同功能，而不考慮這些類之間的層次關係，接口就是實現類對外的外觀。

上面那樣說，可能顯得很裝13，那千言萬語化成一句人話就是：一、定義功能，對外暴露   二、對內約束實現類的行爲

面向接口編程的意義

所謂面向接口去編程的核心含義就是爲了——「封裝隔離」

一般的封裝，是指對數據結構的封裝，將幾種數據類型整到一塊，組成一個新的數據類型；而java中的封裝，包含對數據和行爲進行抽象，而後定義出一個類，這個類即封裝了數據和行爲，但接口這裏的封裝，更多的是指對於行爲（能力、方法）的封裝，是一種「對被隔離體能力的封裝」，而隔離對應的就是，外部的調用以及內部的實現，外部只根據接口來調用方法（根據菜單來點菜，具體填飽肚子的菜是內部去作），外部調用是不知道內部你是用什麼方式實現的，舉個例子，就像我有一個計算器，計算器的加減乘除按鍵就是我提供給用戶的接口，用戶只知道我有加減乘除的能力，但當他用乘法按鍵去運算的時候，後臺具體是用二進制運算，仍是逐個數累加或者其餘什麼方式來完成這個乘法功能，用戶是不知道的。也就是外部調用和內部實現是被隔離開的。

既然外部調用和內部實現被隔離開了，那麼只要接口不變，內部實現怎麼變化都不會影響外部應用對這個接口的調用，從而讓系統更加的靈活，更便於擴展和維護，也就是傳說中的「接口是系統可插拔的保證」。

說到這裏插一段題外話，emmm……我的感受編程是一我的的事，不少時候1+1<2，由於人這個不可控因素，每一個程序員的思想深度，技術水平，都是不相同的，因此每每會出現 「 一個程序員A費勁心力，設計了面向對象的模塊化代碼結構，並完成了一部分功能，然後面有別的需求介入，另外一個的程序員B加入了研發過程，基於這個代碼進行改動的時候，並讀不懂A的結構和A事先預留的擴展方式，直接用他的方式去硬編碼，強行破壞了整個結構」。以上這種狀況每每很使人崩潰，因此對於水平良莠不齊的團隊來講，集體勞做的質量（單指代碼）並不那麼友好

總之，在開發中，優先選擇使用接口，在即要定義子類的行爲，又要爲子類提供公共方法的時候選擇抽象類。

從設計上來體會接口的意義

這裏我們從我我的比較熟悉的java入手，在java的設計中，常常出現的層的概念和模塊的概念，我的常常作java Web的程序，咱們以此爲例，最經典的MVC結構，抽象一點理解，也就是控制、邏輯、數據三層，它們之間所有經過接口來通訊。

在每一層裏，又包含不少模塊，每一個模塊對外則是一個總體，因此一個模塊應該對外提供接口，其餘地方須要某個功能時，可根據接口直接調用模塊，也就是上面的 「 接口是被其隔離部分的外觀」。

設計中常常會提到組件，模塊，其實不管是組件仍是模塊，均可以理解爲 封裝了必定功能的集合體， 一個類，一個功能塊，一個插件，一個系統，均可以理解成組件、模塊，由於，一個類多是一個功能塊的一部分，一個功能塊多是一個插件的一部分，一個插件多是一個系統的一部分，小系統放到大系統中，也就是個組件罷了，就是組合的關係，從設計的角度，系統，子系統，插件、模塊、組件等，其實說的就是一個東西，就是完成必定功能的封裝體。

 

簡單工廠

前面咧咧了那麼多，看官們確定看煩了，差評差評！這裏我上面說了那麼多接口的東西，總得用來看看吧，咱們用一個例子來切入主題，這裏我打算寫一個功能，就是比對兩個字符串類似的程度，確定會有人說了，你這真廢話，直接 equals() 它不香麼！香是香，但是它不能展現(讓我裝13啊)呀，咱們以java的方式來搞個類似度計算。

上面說了接口，那咱們先定義接口：

public interface MatcherAlg {

    /**
     * 計算兩個串的類似度
     * @param srcStr
     * @param dstStr
     * @return Float 類似值
     */
   public Float CalculateSimilarityRatioValue(String srcStr,String dstStr);



}

接口已經約束了咱們這個功能只有一個方法，那麼咱們來內部實現一下：

public class JaccardMatcher implements MatcherAlg {

    @Override
    public Float CalculateSimilarityRatioValue(String srcStr, String dstStr) {
        if(srcStr == null && dstStr ==null){
            return 1f;
        }
        if(srcStr == null || dstStr == null){
            return 0f;
        }
        Set<Integer> aChar = srcStr.chars().boxed().collect(Collectors.toSet());
        Set<Integer> bChar = dstStr.chars().boxed().collect(Collectors.toSet());

        int intersection = SetUtils.intersection(aChar,bChar).size();
        if(intersection == 0){
            return 0f;
        }
        int union =  SetUtils.union(aChar,bChar).size();
        return ((float)intersection/(float)union);
    }
}

這時候咱們要用它了，來比較兩個字符串類似程度：

public class Test{
  
   public static void main(String args[]){
        String str= "sdfsf";
        String dst= "1234d";
        MatcherAlg matcher = new JaccardMatcher();
        Float result = matcher.CalculateSimilarityRatioValue(str,dst);
    }

}

　　運行一下，也十分正常，完美落地，但是仔細看下來，這樣我定義那個 MatcherAlg 接口，後面又 

　　MatcherAlg matcher = new JaccardMatcher();

好像是在 「脫了褲子放p」，沒事找事。幹嗎不直接定義JaccardMatcher類，而後：

JaccardMatcher matcher = new JaccardMatcher();

可是上面說過了，咱們應該面向接口編程，接口的核心就爲了 「封裝隔離」，實現類JaccardMatcher應該是被接口 MatcherAlg封裝並同客戶端隔離開來。

客戶端根本不該該知道 JaccardMatcher的存在，更不用說 new JaccardMatcher（）這種「脫褲放p」操做了。可是問題又來了，若是客戶端沒有new JaccardMatcher（），只有MatcherAlg接口的定義，那麼後面的代碼是沒法使用的。

因而糾結的地方出現了，上面花了那麼大篇幅說怎麼怎麼面向接口，純面向接口了你又不能運行了，能運行又違反了「隔離封裝」了， 問題進入死環了。

 因此「脫褲放p」的操做是對應這個死環一種蹩腳的寫法（它能夠運行，但專業的咱們不認）。

這個死環如何解決，咱們先看一下設計模式中的一段話，它是這樣說的 ：提供一個建立對象實例的功能，而無需關係其具體的實現。被建立實例的類型能夠是接口、抽象類、也能夠是具體的類。

受到那句話的啓發，咱們嘗試得出一個解開上面那個死環的方案：咱們在模塊內部建一個類，這個類的功能就是建立可以使用的接口，而且把建立的接口提供給客戶端，這一客戶只須要根據這個類來獲取相應的接口對象，於此同時，接口具體使用哪一個實現，咱們就能夠抽離到這個類裏面，給咱們提供了一個控制 使用哪一個類的 隔離擴展區，客戶端也不須要關心他用的這個類是對應哪一種實現，如何實現的。

上面這套思想，設計模式中稱之爲 「工廠」

簡單工廠的模式結構

樣例代碼：

//客戶端類
public class Client {
    public static void main(String[] args) {
        Product p = SimpleFactory.makeProduct(Const.PRODUCT_A);
        p.show();
    }
}

//抽象產品
    public interface Product {
        void show();
    }
    //具體產品：ProductA
    public class ConcreteProduct1 implements Product {
        public void show() {
            System.out.println("具體產品1顯示...");
        }
    }
    //具體產品：ProductB
    public class ConcreteProduct2 implements Product {
        public void show() {
            System.out.println("具體產品2顯示...");
        }
    }

   //枚舉
   public final class Const {
        static final int PRODUCT_A = 0;
        static final int PRODUCT_B = 1;
        static final int PRODUCT_C = 2;
    }
　　//工廠
    public class SimpleFactory {
        public static Product makeProduct(int kind) {
            switch (kind) {
                case Const.PRODUCT_A:
                    return new ConcreteProduct1();
                case Const.PRODUCT_B:
                    return new ConcreteProduct2();
            }
            return null;
        }
    }

對簡單工廠的理解

簡單工廠的意義

首先看上面簡單工廠的樣例代碼，有人會困惑，不就是把new操做從客戶端移動到了額外的類裏去了麼，本質仍是new 了一個實現類，這裏咱們再次回到原點，咱們前面提到的接口，接口是用來封裝隔離的，目的就是讓客戶端不要知道封裝體內的具體實現，簡單工廠的位置是處於封裝體內的，簡單工廠跟接口的具體實如今一塊兒，算是封裝體內部的一個類，因此簡單工廠知道具體的實現類是沒有關係的，咱們再來看一下簡單工廠的類圖：

圖中淺藍色的虛線框即爲一個封裝的邊界，表示接口、工廠、實現類組合成了一個組件，在這個組件中，只有接口和工廠是對外的，也只有這倆，外界可使用和訪問到，可是具體的實現類，徹底是內部的，對外透明的，不可見的，因此它被全包裹進藍框，對於客戶端而言，它只知道這個Alg接口和生產含有Alg功能實例的工廠，經過Factory就能獲取Alg的能力了，因此，new操做劃在工廠內，在設計和隔離的意義上，有了質的變化。

簡單工廠的別稱

靜態工廠

所謂靜態工廠，就是咱們使用工廠的時候，不須要實例化工廠了，直接將生產的方法設爲靜態方法，經過類名便可調用，或者作成單例的模式，也就是說簡單工廠的方法一般都是靜態的，因此稱之爲靜態工廠。

萬能工廠

一個簡單工廠能夠包含不少用來構建東西的方法，這些方法能夠建立不一樣的接口、實力類，一個簡單的工廠理論上能夠構造任何東西，因此又稱之爲「萬能工廠」

簡單工廠的本質

簡單工廠的本質是：選擇實現

選擇實現，重點在於選擇，實現是已經作好了的，就算實現再簡單（哪怕是new實例）也要由具體的實現類來實現，而不是在簡單工廠裏面來實現，簡單工廠的目的在爲客戶端提供一個選擇，選擇哪一種實現，從而使客戶端和具體的實現之間解耦。這樣具體實現不管如何變更，都不須要客戶端隨之變更，這個變更會在工廠這一層裏被吸取和隔斷。

實現簡單工廠的難點在於「選擇」的實現，能夠經過傳參，也能夠經過動態的參數，好比在運行期間去讀取配置文件或數據庫、內存中的某個值，根據這個值來進行具體的實現。

擴展簡單工廠：提供可配置的簡單工廠

基本的實現套路，已經有較爲明確的模板了，如今有一個問題，就是若是MatcherAlg的實現類不止一個，咱們能夠經過在工廠的方法中傳入參數來處理

public Class Factory{

  public static MatcherAlg createAlg(String type){

        if( type.equals("a") ){
            return new aAlg();
        }else if ( type.equals("b") ){
            return new bAlg();
        }else{
               ……
        }

}
}

但是，當咱們又又擴展了新的實現類的時候，if else 又須要擴展一句，同時對客戶端也要告知，這樣對於Factory這個類來講，嚴重違反了開閉原則。

爲了解決這個問題，咱們能夠經過配置文件的形式來解決，當有了新的實現類或者須要默認指定用哪個實現的時候，只須要經過配置文件的配置項便可，經過配置文件的方式，多須要使用java的反射來支持動態創建對象。這裏摘取本身的一個代碼來做爲一個樣例：

/**
 * 基礎工廠，其餘組件工廠的實現可用基於該類進行擴展
 * 功能：根據配置文件動態生成對象
 * @author GCC
 */
public abstract class AbstractFactory {

    private static Logger logger = Logger.getLogger(AbstractFactory.class);

    //默認自帶的類控制配置文件
    private final static String DEFAULTCONFIG_FILE_URL = "factoryconfig.ini";

    //默認的配置文件
    static URL defaultConfigFileUrl = AbstractFactory.class.getClassLoader().getResource(DEFAULTCONFIG_FILE_URL);

    /**
     * 根據配置文件以及key值，獲取對象的類路徑
     * @param url   配置文件路徑
     * @param key   關鍵字
     * @return  String 類路徑
     */
    static String getClassUrl(String url,String key){
        ConfigUtil config = new ConfigUtil(url);
        return config.getValueByConfigkey(key);
    }

    /**
     * 根據指定配置文件及指定關鍵字生成對象
     * @param url   配置文件路徑
     * @param key   關鍵字
     * @return  Object 具體對象
     */
    static Object getObject(String url,String key){
        String classurl = getClassUrl(url,key);
        try{
            Class oneclass = Class.forName(classurl);
            return oneclass.newInstance();
        }catch (Exception e){
            logger.error(e.getMessage() +" plase check"+ DEFAULTCONFIG_FILE_URL );
        }
        return null;
    }



}

　　配置文件（.ini文件）內容：

#matcher.algclassurl:算法類地址
matcher.algclassurl=org.gds.matcher.impl.LevenshteinMacther

簡單工廠的缺陷

簡單工廠實現簡單，很是友好的提供了一套實現組件封裝的功能，同時也解決了客戶端何內部實現類的強耦合，實現瞭解耦。這是簡單工廠的優勢，但世事都是兩面的，它也有不可避免地缺點：

首先，它增長了客戶端的複雜程度，若是經過客戶端的參數來選擇具體的實現類，那客戶端必須額外須要一份枚舉表或者字典，而且知道每一個枚舉的意義，這樣會增長客戶端的複雜程度，同時必定程度上暴露了內部的實現（雖然可配置方案必定程度上能夠對衝這一問題）。

其次，簡單工廠使用靜態方法（又叫靜態工廠）來建立接口，當面臨一些複雜的組件建立，靜態方法會很是龐大，沒法經過繼承來擴展建立接口的方法的行爲了。