一般而言，工廠模式分為3種，簡單工廠模式，工廠方法模式，抽象工廠模式。這三種工廠模式逐層深入吧。 一，從springWeb.jar包使用抽象工廠模式的一個例子聊起 之前對spring各種痴迷，所以在需要發送http請求時，用了spring自帶的http客戶端，上代碼： 上UML圖，首先是工廠類： 產 ...
一般而言，工廠模式分為3種，簡單工廠模式，工廠方法模式，抽象工廠模式。這三種工廠模式逐層深入吧。
一，從springWeb.jar包使用抽象工廠模式的一個例子聊起
之前對spring各種痴迷，所以在需要發送http請求時，用了spring自帶的http客戶端，上代碼：
import java.io.InputStream; import java.net.URI; import java.nio.charset.Charset; import org.springframework.http.HttpMethod; import org.springframework.http.client.ClientHttpRequest; import org.springframework.http.client.ClientHttpRequestFactory; import org.springframework.http.client.ClientHttpResponse; import org.springframework.http.client.SimpleClientHttpRequestFactory; import org.springframework.util.StreamUtils; public class Client { public static void main(String[] args) throws Exception{ URI uri = new URI("https://www.cnblogs.com/"); //新建一個抽象ClientHttpRequest工廠 ClientHttpRequestFactory chrf = new SimpleClientHttpRequestFactory(); //生產一個抽象ClientHttpRequest ClientHttpRequest req = chrf.createRequest(uri, HttpMethod.GET); //ClientHttpRequest執行execute方法 ClientHttpResponse res = req.execute(); InputStream is = res.getBody(); String strBody = StreamUtils.copyToString(is, Charset.forName("UTF-8")); is.close(); System.out.println(strBody); } }
上UML圖，首先是工廠類：
產品類，因為產品類有點小複雜，先看產品類介面的定義，看這個產品類的定義，你會覺得spring搞那麼複雜幹嘛，為啥不直接開一個統一的介面HttpRequest，
把httpOutputMessage裡面的getBody放進去就好了。
其實仔細想想，spring之所以這麼設計，是遵循“介面隔離原則”。
為啥要遵循這個原則呢？因為看完spring-web-release.jar包後你會發現，httpMessage被三個介面所extends，分別是HttpOutputMessage，HttpInputMessage,HttpRequest。
這三個介面有十多個實現類，如果併在一起，在三個介面中就需要重覆寫3次。
再聊聊HttpOutputMessage，HttpInputMessage，這兩個介面對於springMVC來說是重中之重，是springMVC傳輸的載體，後面我們聊springMVC框架時還會遇到他們。
再看具體的產品實現類，筆者比較喜歡把方法也放進類圖裡面，所以稍微顯得有點臃腫。前面我們看到，clientHttpRequest介面一共有5個介面方法需要子類去實現。
我猜想spring是這樣子想的：
1，先定義幾個抽象類implement那個ClientHttpRequest介面，然後在抽象類中對clientHttpRequest中做基本的實現，和之前筆者分析spring.core.io包裡面想法一模一樣。
這是用到設計模式中的“模版方法”模式，不過模版方法比較簡單，就不單獨開帖聊了。
2，5個介面方法中，在AbstractClientHttpRequest中實現了getHeaders(),getBody(),execute()3個方法，
然後還不省事地給他的子類添加了兩個抽象方法getBodyInternal(HttpHeaders headers)，executeInternal(HttpHeaders headers)，
再悄悄地告訴你，這兩個抽象方法分別有一個抽象類和兩個具體實現類實現了該抽象方法，也就是我們的產品實現類的類圖還沒有畫完，下圖只是畫了冰山一角而已，不過管中窺豹可見一斑，將就看看吧。
3.剩下的兩個介面方法，getURI，getMethod()方法在SimpleStreamingClientHttpRequest具體的實現類中實現。
4,最後再分析下SimpleBufferingClientHttpRequest這個最底層的實現類。getURI，getMethod()是在這個SimpleBufferingClientHttpRequest底層類實現的。同時第2點提到的兩個不省事的抽象方法在SimpleBufferingClientHttpRequest的父抽象類AbstractBufferingClientHttpRequest已經進行了具體的實現。
5.總結，以上幾個類基本上一個介面方法對應著一個@Override，我猜想這是為了符合里氏替換原則（每個父類能用的地方，他的子類替換過去不會有任何影響）。
其實我挺期待父類override祖父類的介面方法，而後，孫子類再override父類的方法的，好像很少有這種用法。
spring用到的這種工廠模式，應該是屬於最複雜的抽象工廠模式吧，繼承樹，產品族什麼的，真的好複雜。
回到剛開始的需求，其實如果只是要發起一個簡單的http請求，用工廠方法模式或者簡單工廠模式就可以了吧。
二：工廠方法模式和簡單工廠模式
舉個慄子，我們來砍掉上述抽象工廠的產品族等等的一些為了拓展而抽象出的類和介面，類圖會變成這個樣子。
筆者故意比上面的類圖多畫了一個工廠實現類，讓ClientHttpRequestFactory這個介面不會顯得很雞肋。用工廠方法模式其實已經能很大程度地增加程式的拓展性了。
將OkHttp3ClientHttpRequestFactory這個工廠具體實現類刪掉，就變成了簡單工廠模式的類圖了。
至此，3種工廠模式已經介紹完了，如有錯漏，還請各位博友批評指正。
