工厂模式（工厂方法模式，抽象工厂模式） Java

工厂模式分为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内部保存的仅仅是一些参数，占用内存小得多，长时间驻留在内存中也没有太大的损害。