目錄面向接口編程接口的定義及功能面向接口編程的意義從設(shè)計(jì)上來體會(huì)接口的意義簡(jiǎn)單工廠簡(jiǎn)單工廠的模式結(jié)構(gòu)對(duì)簡(jiǎn)單工廠的理解簡(jiǎn)單工廠的意義簡(jiǎn)單工廠的別稱簡(jiǎn)單工廠的本質(zhì)擴(kuò)展簡(jiǎn)單工廠：提供可配置的簡(jiǎn)單工廠簡(jiǎn)單工廠的缺陷面向接口編程接口的定義及功能

這里從java介入吧，在java中，接口是一種特殊的類，接口里面的量都是常量，接口的方法只有定義而沒有實(shí)現(xiàn)，換句話說，接口就像一個(gè)菜單，它只會(huì)告知你我有什么菜，而并不會(huì)有實(shí)際的菜品，所以通常用接口來定義實(shí)現(xiàn)類的外觀，根據(jù)外部應(yīng)用所需要的功能，約定實(shí)現(xiàn)類的能力（類的功能不僅限于接口約束）。通過接口，可以實(shí)現(xiàn)不相關(guān)類的相同功能，而不考慮這些類之間的層次關(guān)系，接口就是實(shí)現(xiàn)類對(duì)外的外觀。

上面那樣說，可能顯得很裝13，那千言萬語化成一句人話就是：1、定義功能，對(duì)外暴露 2、對(duì)內(nèi)約束實(shí)現(xiàn)類的行為

面向接口編程的意義

所謂面向接口去編程的核心含義就是為了——“封裝隔離”

通常的封裝，是指對(duì)數(shù)據(jù)結(jié)構(gòu)的封裝，將幾種數(shù)據(jù)類型整到一塊，組成一個(gè)新的數(shù)據(jù)類型；而java中的封裝，包含對(duì)數(shù)據(jù)和行為進(jìn)行抽象，然后定義出一個(gè)類，這個(gè)類即封裝了數(shù)據(jù)和行為，但接口這里的封裝，更多的是指對(duì)于行為（能力、方法）的封裝，是一種“對(duì)被隔離體能力的封裝”，而隔離對(duì)應(yīng)的就是，外部的調(diào)用以及內(nèi)部的實(shí)現(xiàn)，外部只根據(jù)接口來調(diào)用方法（根據(jù)菜單來點(diǎn)菜，具體填飽肚子的菜是內(nèi)部去做），外部調(diào)用是不知道內(nèi)部你是用什么方式實(shí)現(xiàn)的，舉個(gè)例子，就像我有一個(gè)計(jì)算器，計(jì)算器的加減乘除按鍵就是我提供給用戶的接口，用戶只知道我有加減乘除的能力，但當(dāng)他用乘法按鍵去運(yùn)算的時(shí)候，后臺(tái)具體是用二進(jìn)制運(yùn)算，還是逐個(gè)數(shù)累加或者其他什么方式來完成這個(gè)乘法功能，用戶是不知道的。也就是外部調(diào)用和內(nèi)部實(shí)現(xiàn)是被隔離開的。

既然外部調(diào)用和內(nèi)部實(shí)現(xiàn)被隔離開了，那么只要接口不變，內(nèi)部實(shí)現(xiàn)怎么變化都不會(huì)影響外部應(yīng)用對(duì)這個(gè)接口的調(diào)用，從而讓系統(tǒng)更加的靈活，更便于擴(kuò)展和維護(hù)，也就是傳說中的“接口是系統(tǒng)可插拔的保證”。

說到這里插一段題外話，emmm……個(gè)人感覺編程是一個(gè)人的事，很多時(shí)候1+1<2，因?yàn)槿诉@個(gè)不可控因素，每個(gè)程序員的思想深度，技術(shù)水平，都是不相同的，所以往往會(huì)出現(xiàn) “ 一個(gè)程序員A費(fèi)勁心力，設(shè)計(jì)了面向?qū)ο蟮哪K化代碼結(jié)構(gòu)，并完成了一部分功能，而后面有別的需求介入，另一個(gè)的程序員B加入了研發(fā)過程，基于這個(gè)代碼進(jìn)行改動(dòng)的時(shí)候，并讀不懂A的結(jié)構(gòu)和A事先預(yù)留的擴(kuò)展方式，直接用他的方式去硬編碼，強(qiáng)行破壞了整個(gè)結(jié)構(gòu)”。以上這種情況往往很令人崩潰，所以對(duì)于水平參差不齊的團(tuán)隊(duì)來說，集體勞作的質(zhì)量（單指代碼）并不那么友好

總之，在開發(fā)中，優(yōu)先選擇使用接口，在即要定義子類的行為，又要為子類提供公共方法的時(shí)候選擇抽象類。

從設(shè)計(jì)上來體會(huì)接口的意義

這里咱們從我個(gè)人比較熟悉的java入手，在java的設(shè)計(jì)中，經(jīng)常出現(xiàn)的層的概念和模塊的概念，個(gè)人經(jīng)常做java Web的程序，我們以此為例，最經(jīng)典的MVC結(jié)構(gòu)，抽象一點(diǎn)理解，也就是控制、邏輯、數(shù)據(jù)三層，它們之間全部通過接口來通信。

在每一層里，又包含很多模塊，每個(gè)模塊對(duì)外則是一個(gè)整體，所以一個(gè)模塊應(yīng)該對(duì)外提供接口，其他地方需要某個(gè)功能時(shí)，可根據(jù)接口直接調(diào)用模塊，也就是上面的 “ 接口是被其隔離部分的外觀”。

設(shè)計(jì)中經(jīng)常會(huì)提到組件，模塊，其實(shí)不論是組件還是模塊，都可以理解為 封裝了一定功能的集合體， 一個(gè)類，一個(gè)功能塊，一個(gè)插件，一個(gè)系統(tǒng)，都可以理解成組件、模塊，因?yàn)椋粋€(gè)類可能是一個(gè)功能塊的一部分，一個(gè)功能塊可能是一個(gè)插件的一部分，一個(gè)插件可能是一個(gè)系統(tǒng)的一部分，小系統(tǒng)放到大系統(tǒng)中，也就是個(gè)組件罷了，就是組合的關(guān)系，從設(shè)計(jì)的角度，系統(tǒng)，子系統(tǒng)，插件、模塊、組件等，其實(shí)說的就是一個(gè)東西，就是完成一定功能的封裝體。

簡(jiǎn)單工廠

前面咧咧了那么多，看官們肯定看煩了，差評(píng)差評(píng)！這里我上面說了那么多接口的東西，總得用來看看吧，我們用一個(gè)例子來切入主題，這里我打算寫一個(gè)功能，就是比對(duì)兩個(gè)字符串相似的程度，肯定會(huì)有人說了，你這真廢話，直接 equals() 它不香么！香是香，可是它不能展示(讓我裝13啊)呀，我們以java的方式來搞個(gè)相似度計(jì)算。

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

public interface MatcherAlg { /** * 計(jì)算兩個(gè)串的相似度 * @param srcStr * @param dstStr * @return Float 相似值 */ public Float CalculateSimilarityRatioValue(String srcStr,String dstStr);}

接口已經(jīng)約束了我們這個(gè)功能只有一個(gè)方法，那么我們來內(nèi)部實(shí)現(xiàn)一下：

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); }}

這時(shí)候我們要用它了，來比較兩個(gè)字符串相似程度：

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); }}

運(yùn)行一下，也十分正常，完美落地，可是仔細(xì)看下來，這樣我定義那個(gè)MatcherAlg 接口，后面又

MatcherAlg matcher = new JaccardMatcher();

好像是在 “脫了褲子放p”，沒事找事。干嘛不直接定義JaccardMatcher類，然后：

JaccardMatcher matcher = new JaccardMatcher();

但是上面說過了，我們應(yīng)該面向接口編程，接口的核心就為了 “封裝隔離”，實(shí)現(xiàn)類JaccardMatcher應(yīng)該是被接口 MatcherAlg封裝并同客戶端隔離開來。

客戶端根本不應(yīng)該知道JaccardMatcher的存在，更不用說 newJaccardMatcher（）這種“脫褲放p”操作了。但是問題又來了，如果客戶端沒有newJaccardMatcher（），只有MatcherAlg接口的定義，那么后面的代碼是無法使用的。

于是糾結(jié)的地方出現(xiàn)了，上面花了那么大篇幅說怎么怎么面向接口，純面向接口了你又不能運(yùn)行了，能運(yùn)行又違反了“隔離封裝”了， 問題進(jìn)入死環(huán)了。

所以“脫褲放p”的操作是對(duì)應(yīng)這個(gè)死環(huán)一種蹩腳的寫法（它可以運(yùn)行，但專業(yè)的我們不認(rèn)）。

這個(gè)死環(huán)如何解決，我們先看一下設(shè)計(jì)模式中的一段話，它是這樣說的 ：提供一個(gè)創(chuàng)建對(duì)象實(shí)例的功能，而無需關(guān)系其具體的實(shí)現(xiàn)。被創(chuàng)建實(shí)例的類型可以是接口、抽象類、也可以是具體的類。

受到那句話的啟發(fā)，我們嘗試得出一個(gè)解開上面那個(gè)死環(huán)的方案：我們?cè)谀K內(nèi)部建一個(gè)類，這個(gè)類的功能就是創(chuàng)建可使用的接口，并且把創(chuàng)建的接口提供給客戶端，這一客戶只需要根據(jù)這個(gè)類來獲取相應(yīng)的接口對(duì)象，于此同時(shí)，接口具體使用哪個(gè)實(shí)現(xiàn)，我們就可以抽離到這個(gè)類里面，給我們提供了一個(gè)控制 使用哪個(gè)類的 隔離擴(kuò)展區(qū)，客戶端也不需要關(guān)心他用的這個(gè)類是對(duì)應(yīng)哪種實(shí)現(xiàn)，如何實(shí)現(xiàn)的。

上面這套思想，設(shè)計(jì)模式中稱之為 “工廠”

簡(jiǎn)單工廠的模式結(jié)構(gòu)

樣例代碼：

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

//抽象產(chǎn)品 public interface Product {void show(); } //具體產(chǎn)品：ProductA public class ConcreteProduct1 implements Product {public void show() { System.out.println('具體產(chǎn)品1顯示...');} } //具體產(chǎn)品：ProductB public class ConcreteProduct2 implements Product {public void show() { System.out.println('具體產(chǎn)品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;} }對(duì)簡(jiǎn)單工廠的理解簡(jiǎn)單工廠的意義

首先看上面簡(jiǎn)單工廠的樣例代碼，有人會(huì)困惑，不就是把new操作從客戶端移動(dòng)到了額外的類里去了么，本質(zhì)還是new 了一個(gè)實(shí)現(xiàn)類，這里我們?cè)俅位氐皆c(diǎn)，我們前面提到的接口，接口是用來封裝隔離的，目的就是讓客戶端不要知道封裝體內(nèi)的具體實(shí)現(xiàn)，簡(jiǎn)單工廠的位置是處于封裝體內(nèi)的，簡(jiǎn)單工廠跟接口的具體實(shí)現(xiàn)在一起，算是封裝體內(nèi)部的一個(gè)類，所以簡(jiǎn)單工廠知道具體的實(shí)現(xiàn)類是沒有關(guān)系的，我們?cè)賮砜匆幌潞?jiǎn)單工廠的類圖：

圖中淺藍(lán)色的虛線框即為一個(gè)封裝的邊界，表示接口、工廠、實(shí)現(xiàn)類組合成了一個(gè)組件，在這個(gè)組件中，只有接口和工廠是對(duì)外的，也只有這倆，外界可以使用和訪問到，但是具體的實(shí)現(xiàn)類，完全是內(nèi)部的，對(duì)外透明的，不可見的，所以它被全包裹進(jìn)藍(lán)框，對(duì)于客戶端而言，它只知道這個(gè)Alg接口和生產(chǎn)含有Alg功能實(shí)例的工廠，通過Factory就能獲取Alg的能力了，所以，new操作劃在工廠內(nèi)，在設(shè)計(jì)和隔離的意義上，有了質(zhì)的變化。

簡(jiǎn)單工廠的別稱

靜態(tài)工廠

所謂靜態(tài)工廠，就是我們使用工廠的時(shí)候，不需要實(shí)例化工廠了，直接將生產(chǎn)的方法設(shè)為靜態(tài)方法，通過類名即可調(diào)用，或者做成單例的模式，也就是說簡(jiǎn)單工廠的方法通常都是靜態(tài)的，所以稱之為靜態(tài)工廠。

萬能工廠

一個(gè)簡(jiǎn)單工廠可以包含很多用來構(gòu)建東西的方法，這些方法可以創(chuàng)建不同的接口、實(shí)力類，一個(gè)簡(jiǎn)單的工廠理論上可以構(gòu)造任何東西，所以又稱之為“萬能工廠”

簡(jiǎn)單工廠的本質(zhì)

簡(jiǎn)單工廠的本質(zhì)是：選擇實(shí)現(xiàn)

選擇實(shí)現(xiàn)，重點(diǎn)在于選擇，實(shí)現(xiàn)是已經(jīng)做好了的，就算實(shí)現(xiàn)再簡(jiǎn)單（哪怕是new實(shí)例）也要由具體的實(shí)現(xiàn)類來實(shí)現(xiàn)，而不是在簡(jiǎn)單工廠里面來實(shí)現(xiàn)，簡(jiǎn)單工廠的目的在為客戶端提供一個(gè)選擇，選擇哪種實(shí)現(xiàn)，從而使客戶端和具體的實(shí)現(xiàn)之間解耦。這樣具體實(shí)現(xiàn)無論如何變動(dòng)，都不需要客戶端隨之變動(dòng)，這個(gè)變動(dòng)會(huì)在工廠這一層里被吸收和隔斷。

實(shí)現(xiàn)簡(jiǎn)單工廠的難點(diǎn)在于“選擇”的實(shí)現(xiàn)，可以通過傳參，也可以通過動(dòng)態(tài)的參數(shù)，比如在運(yùn)行期間去讀取配置文件或數(shù)據(jù)庫、內(nèi)存中的某個(gè)值，根據(jù)這個(gè)值來進(jìn)行具體的實(shí)現(xiàn)。

擴(kuò)展簡(jiǎn)單工廠：提供可配置的簡(jiǎn)單工廠

基本的實(shí)現(xiàn)套路，已經(jīng)有較為明確的模板了，現(xiàn)在有一個(gè)問題，就是如果MatcherAlg的實(shí)現(xiàn)類不止一個(gè)，我們可以通過在工廠的方法中傳入?yún)?shù)來處理

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{ ……}}}

可是，當(dāng)我們又又?jǐn)U展了新的實(shí)現(xiàn)類的時(shí)候，if else 又需要擴(kuò)展一句，同時(shí)對(duì)客戶端也要告知，這樣對(duì)于Factory這個(gè)類來說，嚴(yán)重違反了開閉原則。

為了解決這個(gè)問題，我們可以通過配置文件的形式來解決，當(dāng)有了新的實(shí)現(xiàn)類或者需要默認(rèn)指定用哪一個(gè)實(shí)現(xiàn)的時(shí)候，只需要通過配置文件的配置項(xiàng)即可，通過配置文件的方式，多需要使用java的反射來支持動(dòng)態(tài)建立對(duì)象。這里摘取自己的一個(gè)代碼來作為一個(gè)樣例：

/** * 基礎(chǔ)工廠，其他組件工廠的實(shí)現(xiàn)可用基于該類進(jìn)行擴(kuò)展 * 功能：根據(jù)配置文件動(dòng)態(tài)生成對(duì)象 * @author GCC */public abstract class AbstractFactory { private static Logger logger = Logger.getLogger(AbstractFactory.class); //默認(rèn)自帶的類控制配置文件 private final static String DEFAULTCONFIG_FILE_URL = 'factoryconfig.ini'; //默認(rèn)的配置文件 static URL defaultConfigFileUrl = AbstractFactory.class.getClassLoader().getResource(DEFAULTCONFIG_FILE_URL); /** * 根據(jù)配置文件以及key值，獲取對(duì)象的類路徑 * @param url 配置文件路徑 * @param key 關(guān)鍵字 * @return String 類路徑 */ static String getClassUrl(String url,String key){ConfigUtil config = new ConfigUtil(url);return config.getValueByConfigkey(key); } /** * 根據(jù)指定配置文件及指定關(guān)鍵字生成對(duì)象 * @param url 配置文件路徑 * @param key 關(guān)鍵字 * @return Object 具體對(duì)象 */ 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文件）內(nèi)容：

#matcher.algclassurl:算法類地址matcher.algclassurl=org.gds.matcher.impl.LevenshteinMacther簡(jiǎn)單工廠的缺陷

簡(jiǎn)單工廠實(shí)現(xiàn)簡(jiǎn)單，非常友好的提供了一套實(shí)現(xiàn)組件封裝的功能，同時(shí)也解決了客戶端何內(nèi)部實(shí)現(xiàn)類的強(qiáng)耦合，實(shí)現(xiàn)了解耦。這是簡(jiǎn)單工廠的優(yōu)點(diǎn)，但世事都是兩面的，它也有不可避免地缺點(diǎn)：

首先，它增加了客戶端的復(fù)雜程度，如果通過客戶端的參數(shù)來選擇具體的實(shí)現(xiàn)類，那客戶端必須額外需要一份枚舉表或者字典，并且知道每個(gè)枚舉的意義，這樣會(huì)增加客戶端的復(fù)雜程度，同時(shí)一定程度上暴露了內(nèi)部的實(shí)現(xiàn)（雖然可配置方案一定程度上可以對(duì)沖這一問題）。

其次，簡(jiǎn)單工廠使用靜態(tài)方法（又叫靜態(tài)工廠）來創(chuàng)建接口，當(dāng)面臨一些復(fù)雜的組件創(chuàng)建，靜態(tài)方法會(huì)非常龐大，無法通過繼承來擴(kuò)展創(chuàng)建接口的方法的行為了。

以上就是如何從Java接口的角度切入靜態(tài)工廠模式的詳細(xì)內(nèi)容，更多關(guān)于從Java接口的角度切入靜態(tài)工廠模式的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！