java设计模式之：工厂模式详解（简单工厂+工厂方法+抽象工厂）

---

在面向对象编程中，创建对象实例最常用的方式就是通过 new 操作符构造一个对象实例，但在某些情况下，new 操作符直接生成对象会存在一些问题。举例来说，对象的创建需要一系列的步骤：可能需要计算或取得对象的初始位置、选择生成哪个子对象实例、或在生成之前必须先生成一些辅助对象。 在这些情况，新对象的建立就是一个 “过程”，而不仅仅是一个操作，就像一部大机器中的一个齿轮传动。

针对上面这种情况，我们如何轻松方便地构造对象实例，而不必关心构造对象示例的细节和复杂过程？解决方案就是使用一个工厂类来创建对象。

简单工厂

在创建一个对象时不向客户暴露内部细节，并提供一个创建对象的通用接口。

简单工厂把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应该用哪个具体子类来实例化。

这样做能把客户类和具体子类的实现解耦，客户类不再需要知道有哪些子类以及应当实例化哪个子类。

客户类往往有多个，如果不使用简单工厂，那么所有的客户类都要知道所有子类的细节。而且一旦子类发生改变，例如增加子类，那么所有的客户类都要进行修改。

实现

我们以生产工厂为例，定义一个生产工厂Product接口：

public interface Product
{
    /**
     * 生产
     */
    void product();
}

创建一个 ConcreteProduct1 类的实现 Product 类：

public class ConcreteProduct1 implements Product
{
    @Override
    public void product()
    {
        System.out.println("生产产品1");
    }
}

以下的 Client 类包含了实例化的代码，这是一种错误的实现。

public class Client
{
    public static void main(String[] args)
    {
        Product product = new ConcreteProduct1();
        product.product();
    }
}

看上面的代码，父类 Product 指向子类 ConcreteProduct1 的引用，应用层代码需要依赖 ConcreteProduct1，如果业务扩展，我继续增加 ConcreteProduct2 甚至更多，那么我们客户端的依赖会变得越来越臃肿。因此，我们要想办法把这种依赖减弱，把创建细节隐藏。虽然目前的代码中，我们创建对象的过程并不复杂，但从代码设计角度来讲不易于扩展。现在，我们用简单工厂模式对代码进行优化。先增加 ConcreteProduct2 类：

public class ConcreteProduct2 implements Product
{
    @Override
    public void product()
    {
        System.out.println("生产产品2");
    }
}

以下的 SimpleFactory 是简单工厂实现，它被所有需要进行实例化的客户类调用。

public class SimpleFactory
{
    public static Product createProduct(String name)
    {
        if ("product1".equals(name))
        {
            return new ConcreteProduct1();
        }
        else if ("product2".equals(name))
        {
            return new ConcreteProduct2();
        }
        else
        {
            return null;
        }
    }
}

public class Client
{
    public static void main(String[] args)
    {
        Product product = SimpleFactory.createProduct("product2");
        product.product();
    }
}

现在客户端调用是不是就简单了呢，但如果我们业务继续扩展，要增加ConcreteProduct3，那么工厂中的createProduct()就要根据产品的增加每次都要修改代码逻辑。不符合开闭原则。因此，我们对简单工厂还可以继续优化，可以采用反射技术：

public class SimpleFactory
{
    public static Product createProduct(Class<? extends Product> clazz)
    {
        if (clazz != null)
        {
            try
            {
                return clazz.newInstance();
            }
            catch (Exception e)
            {
                e.printStackTrace();
            }
        }
        return null;
    }
}

public class Client
{
    public static void main(String[] args)
    {
        Product product = SimpleFactory.createProduct(ConcreteProduct2.class);
        product.product();
    }
}

优化之后，产品不断丰富不需要修改 SimpleFactory 中的代码，简单工厂到这里就结束了。

应用场景

下面这个代码大家应该很熟悉

Logger logger = LoggerFactory.getLogger(CacheManager.class);

我们进源码看看它的实现，就知道它采用的正是简单工厂模式

public static Logger getLogger(String name) {
    ILoggerFactory iLoggerFactory = getILoggerFactory();
    return iLoggerFactory.getLogger(name);
}

public static Logger getLogger(Class<?> clazz) {
    Logger logger = getLogger(clazz.getName());
    if (DETECT_LOGGER_NAME_MISMATCH) {
        Class<?> autoComputedCallingClass = Util.getCallingClass();
        if (autoComputedCallingClass != null && nonMatchingClasses(clazz, autoComputedCallingClass)) {
            Util.report(String.format("Detected logger name mismatch. Given name: \"%s\"; computed name: \"%s\".", 		                            logger.getName(), autoComputedCallingClass.getName()));
            Util.report("See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation");
        }
    }

    return logger;
}

工厂方法

定义了一个创建对象的接口，但由子类决定要实例化哪个类。工厂方法把实例化操作推迟到子类。

在简单工厂中，创建对象的是另一个类，而在工厂方法中，是由子类来创建对象。

下图中，Factory 有一个 doSomething() 方法，这个方法需要用到一个产品对象，这个产品对象由 factoryMethod() 方法创建。该方法是抽象的，需要由子类去实现。

实现

定义一个Factory抽象方法

public abstract class Factory
{
    //创建产品对象
    abstract public Product factoryMethod();

    public void doSomething()
    {
        Product product = factoryMethod();
        // do something with the product
    }
}

创建子类ConcreteFactory1

public class ConcreteFactory1 extends Factory
{
    @Override
    public Product factoryMethod()
    {
        return new ConcreteProduct1();
    }
}

创建子类ConcreteFactory2

public class ConcreteFactory2 extends Factory
{
    @Override
    public Product factoryMethod()
    {
        return new ConcreteProduct2();
    }
}

适用场景

1. 创建对象需要大量重复的代码。
2. 客户端（应用层）不依赖于产品类实例如何被创建、实现等细节。
3. 一个类通过其子类来指定创建哪个对象。

缺点

1. 类的个数容易过多，增加复杂度。
2. 增加了系统的抽象性和理解难度。

抽象工厂

提供一个接口，用于创建 相关的对象家族 。

抽象工厂模式创建的是对象家族，也就是很多对象而不是一个对象，并且这些对象是相关的，也就是说必须一起创建出来。而工厂方法模式只是用于创建一个对象，这和抽象工厂模式有很大不同。

抽象工厂模式用到了工厂方法模式来创建单一对象，AbstractFactory 中的 createProductA() 和 createProductB() 方法都是让子类来实现，这两个方法单独来看就是在创建一个对象，这符合工厂方法模式的定义。

至于创建对象的家族这一概念是在 Client 体现，Client 要通过 AbstractFactory 同时调用两个方法来创建出两个对象，在这里这两个对象就有很大的相关性，Client 需要同时创建出这两个对象。

从高层次来看，抽象工厂使用了组合，即 Cilent 组合了 AbstractFactory，而工厂方法模式使用了继承。

实现

public class AbstractProductA {
}

public class AbstractProductB {
}

public class ProductA1 extends AbstractProductA {
}

public class ProductA2 extends AbstractProductA {
}

public class ProductB1 extends AbstractProductB {
}

public class ProductB2 extends AbstractProductB {
}

public abstract class AbstractFactory {
    abstract AbstractProductA createProductA();
    abstract AbstractProductB createProductB();
}

public class ConcreteFactory1 extends AbstractFactory {
    AbstractProductA createProductA() {
        return new ProductA1();
    }

    AbstractProductB createProductB() {
        return new ProductB1();
    }
}

public class ConcreteFactory2 extends AbstractFactory {
    AbstractProductA createProductA() {
        return new ProductA2();
    }

    AbstractProductB createProductB() {
        return new ProductB2();
    }
}

public class Client {
    public static void main(String[] args) {
        AbstractFactory abstractFactory = new ConcreteFactory1();
        AbstractProductA productA = abstractFactory.createProductA();
        AbstractProductB productB = abstractFactory.createProductB();
        // do something with productA and productB
    }
}

缺点

1. 规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口。
2. 增加了系统的抽象性和理解难度。