Java设计模式之-工厂模式和抽象工厂模式

很多人应该都见过名为XXXFactory()的方法，而看到工厂（Factory）便立刻联想到设计模式中的工厂模式和抽象工厂模式。我也是这样，但是一直都没有考究过工厂模式到底是干什么的，提供了什么便利，应该怎样实现。
最近在学习过程中看了很多文章材料，对工厂模式和抽象工厂模式有了一定的了解，但是网上很多文章都在大谈特谈如何写一个简单的工厂模式，却没有说到底什么是工厂模式。我也是最后直接在GoF的英文书里面才找到当时对抽象工厂和工厂模式的定义：

工厂模式（Factory）：Define an interface for creating an object, but let subclasses decide which class
to instantiate. Factory Method lets a class defer instantiation to subclasses. （提供一个接口用于类的实例化，但让接口的实现类决定需要实例化哪个类。工厂方法将类的实例化推迟到了接口的实现类中。）

抽象工厂模式（Abstract Factory）：Provide an interface for creating families of related or dependent objects without specifying their concrete classes. （提供一个有创建一组相关对象实例的方法的接口，并且不用制定这些对象的具体类。）

根据上面两个描述，其实工厂模式就是为了隐藏工厂类背后的子类细节，或者为了在客户端不知道应该使用哪个具体子类的时候，仍能够获得一个实例；而抽象工厂则是为一组相关的子类进行实例化的创建，对于工厂本身则是需要指定的。

工厂模式

看了原文后，原来雾里看花的感觉就没有了。为了要保证外界在不知道具体子类的情况下，能够正常进行实例化，我们需要在工厂方法中对子类进行封装。
在实现工厂模式之前，我如果想对一个具体的Product类进行实例化，需要写

Product product = new ConcreteProduct();

如果我不知道这个ConcreteProduct的名字，或无法访问到，或其他种种我无法直接使用new关键字进行实例化时，就有了一种变通的方法：

Product product = ProductFactory.produce();

我们来看一下这个ProductFactory应该怎么写：

public interface IProductFactory{
    public Product produce();
}

public static class ProductFactory implements IProductFactory{
    @Override
    public static Product produce(){
        return new ConcreteProduct();
    }
}

public interface Product(){
}

public class ConcreteProduct implements Product{   
}

这样一来，客户即使不知道应该实例化ConcreteProduct,也能获得一个Product的实例。
但是如果我有多个Product怎么办呢？比如不同条件下，需要使用不同的子类进行实例化，而这个条件是作为参数从外界传入product方法的。我应该如何编写一个合适的工厂呢？
其实我们可以把上一篇文章Java设计模式之-建造者模式中的例子拿过来。其实该文章中的一个Builder接口和两个Builder具体实现就已经是我们说得一个工厂接口和两个不同产品的工厂实现类了。

public class ProductFactory implements IProductFactory {
    private static final int HIGH_QUALITY = 0;
    private static final int NORMAL_QUALITY = 1;

    @Override
    public static Product produce(int choice) {
        Product product = null;
        switch (choice) {
            case HIGH_QUALITY:
                return new HighQualityProduct();
            case NORMAL_QUALITY:
                return new NormalProduct();
            default:
                throw new IllegalArgumentException();

        }
    }
}

而我们在调用的时候需要传入一个参数表示使用哪种产品Product product = ProductFactory.produce(0);
我看了网上很多说这样会在增加更多产品时，让工厂方法发生修改。还有推荐使用反射方式，将类的class传入进来，而后反射回一个实例。但是工厂模式的目的就是让子类决定实例化哪个类，上面说的方式与其说在进行工厂，不如说是抖机灵，或者是为了不用new而写代码。

抽象工厂模式

上面也说了，抽象工厂就是为了一组相关联的对象提供实例化的接口，而在GoF的书中也提到了抽象工厂模式就是用工厂模式实现的。与工厂模式相比，抽象工厂其实就是在接口中定义了一组方法，其中每个方法都是用于创建一个整体中的某一个部件的实例。比如我们想实现一个迷宫，那么这个迷宫就需要房间、门和墙：

public interface MazeFactory{
    public Maze createMaze();
    public Room createRoom();
    public Door createDoor();
    public Wall createWall();
}

在迷宫这个概念中，房间、门和墙都是相关联的，互相依赖的。而我们在每一个createXXXX()方法中，其实用到的都是工厂模式，让外界在不知道具体子类的情况下，获得实例。
如果有两个具体的迷宫工厂ComplexMazeFactory和EasyMazeFactory，我们可以在客户端指定需要获得哪一种工厂，当然也可以再封装一个迷宫工厂的工厂类，通过参数方式获得具体的迷宫工厂。这个就不再展示代码了。

和Builder的关系

其实我边写这篇文章的时候也在边想他们之间的区别。其实Builder模式的实现，其实是用到工厂模式，我无需知道具体使用了哪个Builder进行创建，但是我仍然能够得到一个实例。
然而，两者的侧重点其实是不同的。

• Builder关注的是使用和构造分离，尤其是当构造比较复杂时，直接使用一个Builder进行屏蔽；
• Factory关注的是隐藏信息，隐藏到底使用了什么子类，让客户能够了解更少内部的信息，但是仍然能正常使用产品的功能；

所以其实Builder和Factory可以混用，只要场景合适，两种设计模式能够相辅相成，共同完成构造屏蔽和信息隐藏的目的。

另外还想说一句，学习设计模式，其实是为了看懂代码，理解代码，最终将理念融入自己的思维中。最重要的是理解这种模式是为了达到怎样的目的而存在的。如果一味地追寻如何用代码实现，则偏离了学习设计模式的初衷。