工廠模式分為3類：
* 簡單工廠模式 Simple Factory
* 工廠方法模式 Factory Method
* 抽象工廠模式 Abstract Factory
thinking in Java 中工廠方法模式的例子：

interface Service{
    void method1();
    void method2();
}

interface ServiceFactory{
    Service getService();
}

class Implementation1 implements Service{
    Implementation1() {}
    public
 
 void method1(){System.out.println("implementation1 method1");};
    public void method2(){System.out.println("implementation1 method2");};
    }


class Implementation1Factory implements ServiceFactory{
    public Service getService(){
        return new Implementation1();
    }
}

class Implementation2
 
 implements Service{
    Implementation2(){};
    public void method1(){System.out.println("implementation2 method1");};
    public void method2(){System.out.println("implementation2 method2");};
}   

class Implememntation2Factory implements ServiceFactory{
    public Service getService(){
        return
 
 new Implementation2();
    }
}



public class Factories {
    public static void serviceConsumer(ServiceFactory fact){
        Service s = fact.getService();
        s.method1();
        s.method2();
    }

    public static void main(String[] args){
        serviceConsumer(new Implementation1Factory());
        serviceConsumer(new Implememntation2Factory());
    }
}

知乎上的一個問題
為什麼在最後Factories中的靜態方法serviceConsumer中，不直接用Service呢？
省掉工廠方法也可以實現多型，直接用Service例項作為引數，向上轉型成Service介面，去耦合。
如：

interface Service{
    void method1();
    void method2();
}
public static void serviceConsumer(Service s){
    s.method1();
    s.method2();
}

工廠模式真正的精髓並不在於多型去耦合，而是在於“工廠模式”，在Design Pattern中，工廠方法模式是和“虛擬工廠模式”，“生成器模式”，“單例模式”在一起，同屬於建立型模式。
建立型模型最大的共同特徵就是，把型別的定義過程和例項化過程分離開。即在類自身構造器之外，附加一個經常被誤認為沒什麼用的工廠類，如Thinking in Java裡的ServiceFactory：

class ServiceA{
    void method1(){};
    void method2(){};
    // 構造器
    ServiceA(){};
}
class ServiceFactory{
    Service getService(){};
}

實際中，工廠類作用巨大。
當一個類有很多不同的變種時，就需要工廠類來隔離例項化過程。

class ServiceFactory{
    Service getService(){
        if(a){
            ServiceA sA = new ServiceA();
        }else(b){
            ServiceB sB = new ServiceB();
        }else(c){
            ServiceC sC = new ServiceC();
        }
    }
}

這確實有用，但實際生活中，這並不是逼迫我們決定分離出工廠類的最主要的原因。真正的原因是：相比於繼承，我們更優先使用組合。
真正迫使我們決定分離出工廠類的原因，是實體類使用了組合，而且元件又非常的多，如果Service是由很多元件構成的龐大的傢伙，比如一個迷宮：假設一個迷宮是由三種不同的小單元組成，為房間，牆，門。

class Maze{
    Room r1;
    Room r2;
    ...
    Wall w1;
    Wall w2;
    ...
    Door d1;
    Door d2;
    ...
    //構造器
    Maze(){
        //按順序擺放成員欄位元件
        ...
    }
}

問題是，要生成一個迷宮，要成百上千個門，牆，房元件。而且還要遵循一定的邏輯規則，因此構造器就會很複雜，迷宮有無數種，如果給每個迷宮都建立一個實體類，再給出具體構造流程，那就累死了。

這種情況下，合理的辦法是寫一個隨機迷宮生成器，能根據具體要求不同生成無數種迷宮，這就是建立型模式的意義所在。無論是“虛擬工廠模式”，還是“生成器”模式，工廠模式，都是在具體生成的策略上做文章，但一個大前提不變：具體產出的產品Product都是由很多小的元件組合而成，而且組裝的時候靈活度非常高，甚至是runtime使用者定製的，或者是隨機的。這就導致組合出來的產品Product單獨作為一個類存在的意義很小，反而是構造器的作用被放大。索性把構造過程獨立出來成為一個方法，把這個方法用到的引數作為成員欄位一起封裝起來，再來個構造器只負責初始化這些引數，這種累就是“工廠類”。

class MazeFactory{
    //巨大迷宮生成演算法
    Maze mazeGenerator(int roomNum, int wallNum, int doorNum){
        ...
    }
    //構造器 初始化生成迷宮的引數
    MazeFactory(){
        roomNum = 100;
        wallNum = 1000;
        doorNum = 200;
    }
    //欄位：生成迷宮的引數
    int roomNum;
    int wallNum;
    int doorNum;
}

原來的那個迷宮類，本身的構造器不承擔任何功能了。

class Maze{
    void play(){...}

    Maze(int roomNum, int wallNum, int doorNum){
        Room[] roomSet = new Room[roomNum];
        Wall[] wallSet = new Wall[wallNum];
        Door[] doorSet = new Door[doorSet];
    }

    Room[] roomSet;
    Wall[] wallSet;
    Door[] doorSet;

}

所以再回到工廠方法，書裡說的所有的東西，都是基於這個前提，也就是我們說好了啊，迷宮這東西的類檔案裡是沒有具體構造方法的，都是要用工廠類MazeFactory來生成的。至於後來，我們加入了方迷宮，和方迷宮生成器。又有了圓迷宮和圓迷宮生成器。有了一堆生成器複雜了之後，又想到用多型來解耦，這都是後話，是在確定了使用工廠類的前提下，利用多型解耦的優化方案。所以才有了最初的這段程式碼：

//兩個介面
interface Maze{
    void play();
}
interface MazeFactory{
    Maze mazeGenerator();   
}

//各自繼承類
CircularMaze implements Maze{
    ...
}
SquareMaze implements Maze{
    ...
}

CircularFactory implements MazeFactory{
    ...
}
SquareMazeFactory implements MazeFactory{
    ...
}

//多型，面向介面
public static void mazeGame(MazeDactory fact){
    Maze z =  fact.mazeGenerator();
    z.play();
}

public static void serviceConsumer(Service s){
    s.method1();
    s.method2();
}

Service從哪來呢？當然是從其他地方new了傳進來：

Service s = new ServiceA();
serviceConsumer(s);

Service為什麼是一個介面？

ServiceA s = new ServiceA();
s.method1();
s.method2();

如果有一天，領導要求將資料庫從MYSQL換成ACCESS，因為只有一個ServiceA所以只能把所有用到ServiceA的地方都替換成ServiceB:

//!ServiceA s = new ServiceB();
ServiceB s = new ServiceB();
s.method1();
s.method2();

如果是個小專案，沒關係，如果是一個龐大的團隊專案，，，根據設計原則中的依賴倒置原則，設計一個介面，然後擴充套件一個類，這樣就能靈活應對boss的需求了：

Service s;
if (Config.DB == SQL)
    s = new ServiceA();
else if (Config.DB == ACCESS)
    s = new ServiceB();
s.method1();
s.method2();

又過了幾天，用到的資料庫越來越多，if else也越來越多，我麼你決定隔離這些變化，將Service例項化過程放在一個地方，簡單工廠誕生：

Service s = ServiceFactory.getService(Config.DB);
s.method1();
s.method2();

public class ServiceFactory{
    public static Service getService(DB db){
        if(db == SQL)
            return new SerivceA();
        else if(db == ACCESS)
            return new ServiceB();
        else
            return null;
    }
}

這樣，即時資料庫不斷變化，我也只需要擴充套件一個新的類，並且修改工廠這個類就行了。但是ServiceFactory是一個介面，這就是抽象工廠。

另一位回答者接下去回答：
如果只有一個工廠，但同一個Service在不同環境下會有不同的實現，如果環境很多，這個ServiceFactory會變成什麼樣呢：

class ServiceFactory{
    Environment env;
    public static Service getService(){
        if(env == MYSQL){
            return new ServiceA(arg1, arg2,...)
        }else if (env == ORACLE){
            return new ServiceB(arg1, arg2,...);
        }else if (env == BIG_TABLE){
            return new ServiceC(arg1, arg2,...);
        }
    }
}

那麼if else越來越多，每次修改都需要重新編譯整個Factory，而且，一般情況下，實現這些Service的往往是不同組的人，每個組都往這個類里加引數/狀態，合併程式碼時會出現無數個衝突，還可能互相用錯引數從而影響別人程式碼，抽象工廠大家的實現分開到不同的類裡面，讓大家各改各的檔案，互不影響：

//小組1的檔案：
class MySqlFactory implements ServiceFactory{
    public static Service getService(){
        //計算 arg1, arg2,...
        return new ServiceA(arg1, arg2);
    }
}

//小組2的檔案
class OrcaleFactory implements ServiceFactory{
    public static Service getService(){
        //計算arg1, arg2, ...
        return new ServiceB(arg1, arg2);
    }
}
...

這些工廠不需要使用時才new，只要事先new好，存入一個Map，根據具體環境隨時呼叫：

Map<Environment, ServiceFactory> factoryMap = new HashMap<>();
factoryMap.put(MYSQL, new MySqlFactory());
factoryMap.put(ORACLE, new OracleFactory());
...

然後呼叫serviceConsumer的那個地方只需要：

Environment env = ...//獲得環境變數env
ServiceFactory factory = factoryMap.get(env);
serviceSonsumer(factory);

以後如果有新的資料庫，重新寫一個ServiceFactory的實現類，編譯一下放一塊就行，在factoryMap裡放入例項就好了，別的程式碼完全不需要動，甚至不需要重新編譯。
可不可以不要Factory，直接用ServiceMap呢？

Map<Environment, Service> serviceMap = new HashMap<>();
serviceMap.put(MYSQL, new ServiceA(..));
serviceMap.put(ORACLE, new ServiceB(..));

基本是不行的，首先Service的初始化一般需要很多引數，不可能在程式剛載入時就存在，另外Service的例項會new很多個，也不滿足一一對應的關係。但Factory的建構函式一般不需要引數。相比於Service，Factory內部儲存的僅僅是一些引數，佔用記憶體小得多，長時間駐留在記憶體中也沒有太大的損害。