面向介面程式設計
介面的定義及功能
這裡從java介入吧，在java中，介面是一種特殊的類，介面裡面的量都是常量，介面的方法只有定義而沒有實現，換句話說，介面就像一個選單，它只會告知你我有什麼菜，而並不會有實際的菜品，所以通常用介面來定義實現類的外觀，根據外部應用所需要的功能，約定實現類的能力（類的功能不僅限於介面約束）。通過介面，可以實現不相關類的相同功能，而不考慮這些類之間的層次關係，介面就是實現類對外的外觀。
上面那樣說，可能顯得很裝13，那千言萬語化成一句人話就是：1、定義功能，對外暴露 2、對內約束實現類的行為
面向介面程式設計的意義
所謂面向介面去程式設計的核心含義就是為了——“封裝隔離”
通常的封裝，是指對資料結構的封裝，將幾種資料型別整到一塊，組成一個新的資料型別；而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
簡單工廠的缺陷
簡單工廠實現簡單，非常友好的提供了一套實現元件封裝的功能，同時也解決了客戶端何內部實現類的強耦合，實現瞭解耦。這是簡單工廠的優點，但世事都是兩面的，它也有不可避免地缺點：
首先，它增加了客戶端的複雜程度，如果通過客戶端的引數來選擇具體的實現類，那客戶端必須額外需要一份列舉表或者字典，並且知道每個列舉的意義，這樣會增加客戶端的複雜程度，同時一定程度上暴露了內部的實現（雖然可配置方案一定程度上可以對衝這一問題）。
其次，簡單工廠使用靜態方法（又叫靜態工廠）來建立介面，當面臨一些複雜的元件建立，靜態方法會非常龐大，無法通過繼承來擴充套件建立介面的方法的行為了。