設計模式總綱——工廠方法模式

　　接上文，自小陳，聯繫了小做坊工廠以後，生產出了幾千件產品以後，把他的那三件產品擺上了網店，而且在微信中宣傳以後，得到了一致好評，購買者絡繹不絕，特別是騎士隊隊徽，正值NBA東西部決賽，賣的特別火熱，一會兒就脫銷了，這時候小陳想擴大產品線，又生產了一大批的圖紙，包括了一系列NBA中的其餘球隊的徽章和一些其餘的小玩意，打算聯繫這個小做坊工廠，想讓其也一塊兒生產這些產品，可是這個小工廠表示迫不得已，由於這個工廠實在是過小了，若是要擴充產品線的話，必須把原來的機器給拆了，從新組裝裏面的圖紙，並且由於圖紙太多，會致使機器內部臃腫不堪，不堪重負，因此這個小做坊也表示迫不得已。

　　恰巧這時候雷霆隊和勇士隊酣戰正甘，很多客戶都但願獲得雷霆隊的隊徽和勇士隊的隊徽，並且有的還但願小陳能夠擴充產品系列，生產騎士，雷霆，勇士隊的隊服，這時候小陳是急的像熱鍋上的螞蟻同樣，由於客戶的要求的產品愈來愈多樣，這個小做坊已經知足不了了，這時候廠裏面的主管就獻策了，說認識幾家中大型工廠，能夠解決生產上的問題，小陳一聽，樂不可支的就趕忙讓小做坊的主管聯繫了中大型工廠的主管，而後便駕車前往工廠查看了。

　　到了工廠一看，果真不小，開車繞着工廠一圈居然花了10幾分鐘，聯繫了這家工廠的主管以後，小陳瞭解到了一些具體的消息，這家公司有下屬的多家子公司，並且每一個子公司都分工明確，對於產品，各個子公司作的產品都是單一的，既保證了生產的速率，也保證了生產的質量，不會由於生產過多類型的產品致使混亂，職責單一，說着說着，這個主管給小陳畫了一下他們的公司架構圖....以下：

　　

如圖所示，總部下面分別有多個子工廠,不一樣的子工廠生產不一樣的產品,如工廠A和工廠B，正如設計圖紙Product同樣,須要有具體的產品A和B，而大型工廠就是不同，規範，產品A由工廠A來生產，產品B由工廠B來生產，再也不想小做坊工廠同樣，全部的產品都耦合在一個工廠裏面了，咱們來看看具體的模板代碼：

產品接口,像圖紙同樣，全部的產品都必須有圖紙，既全部的產品都必須實現該接口，像如下的具體產品A，和具體產品B

1 public interface Product {
2     public void productMethod();
3 }

1 public class ConcreteProductA implements Product{
2     @Override
3     public void productMethod() {
4         System.out.println("Create Product A！");
5     }
6 }

1 public class ConcreteProductB implements Product{
2     @Override
3     public void productMethod() {
4         System.out.println("Create Product B！");
5     }
6 }

工廠接口，既總部，全部的分公司，都是由下面總部衍生出來的，具體要生產什麼樣的產品子公司能夠自行決定,但子公司必須遵從總部的指揮，不能脫離總部

1 public interface Factory {
2     public Product createProduct();
3 }

具體生產A產品的工廠和生產B產品的工廠

1 public class ConcreteProductFactoryA implements Factory{
2     @Override
3     public Product createProduct() {
4         return new ConcreteProductA();
5     }
6 }

1 public class ConcreteProductFactoryB implements Factory{
2     @Override
3     public Product createProduct() {
4         return new ConcreteProductB();
5     }
6 }

他們生產的過程以下：

1     @Test
2     public void client(){
3         Factory factory = new ConcreteProductFactoryA();
4         Product product = factory.createProduct();
5         product.productMethod();
6     }

看到這個生產過程，小陳就疑惑了，這樣的話，每次生產的時候都要生產一個工廠嘍？那樣很不划算啊,這個主管默默的點了點頭說，不錯不錯，小陳真是有生意頭腦，固然了，咱們總部是不會這樣子作的，這樣成本過高了，並且咱們實在也負擔不起，每當咱們總部要創建下屬工廠的時候，都會把這個工廠的具體地址登記在案,(將工廠名的信息記錄到配置文件中)，等到須要的時候，咱們直接從記錄冊裏面定位出所需的工廠就是了。（等到須要使用的時候，直接經過反射，讓虛擬機讀取配置文件,自行"找到"該工廠)，咱們的登記範本是這樣的：

1 <?xml version="1.0"?>  
2 <config>  
3     <className>ConcreteProductFactoryC</className>  
4 </config>

因此，當咱們須要擴建子工廠的時候，只須要獲得總部的贊成（實現Factory方法），而後把子工廠的信息登記在案，（把子工廠名記錄到配置文件中），等到須要的時候，咱們就能夠用工廠開始建造所需的東西了，固然了，還須要有圖紙哦。（實現了Product方法的產品）。

小陳驚呼，妙哉，經過一個記錄本就能夠省去了那麼多的成本，也便於管理了，接下來，小陳就把目前的新需求告訴了新主管，而後主管聽了以後，聯繫了幾家子公司，邊開始生產新的所需的產品了，一會兒就生產出了騎士、雷霆、勇士的徽章、隊服，隊旗等產品，小陳另外一方面也聯繫了網店的店長，讓他開始鋪貨，上架出售，一切都層次分明，看來小陳離當上CEO，迎娶白富美，走上人生巔峯的路更近了。。可是後面有個頭大的事情又出現了。

　　欲知下文如何，且聽下文分解。