工厂方法模式

定义

工厂方法模式的定义：

Dfine an interface for creating an object, but let subcalsses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

// 产品抽象类
public abstract class Product {
    public void method0() {
        // 业务逻辑处理
    }
    
    // 抽象方法
    public abstract void method1();
}

// 具体产品类
public class ConcreteProduct0 extends Product {
    public void method1(){
        // 业务逻辑处理
    }
}

public class ConcreteProduct1 extends Product {
    public void method1(){
        // 业务逻辑处理
    }
}

// 抽象工厂类
public abstract class Creator{
    /**
     * 创建一个产品对象，其输入参数类型可以自行设置
     * 通常为String、Enum、Class等，当然也可以为空
     */
    public abstract <T extends Product> T createProduct(Class<T> c);
}
// 具体工厂类
public class ConcreteCreator extends Creator {
    public <T extends Product> T createProduct(Class<T> c) {
        Product product = null;
        try {
            product = (Product) Class.forName(c.getName()).newInstance();
        } catch (Exception e) {
            // 异常处理
        }
        return (T)product;
    }
}

// 场景类
public class Client {
    public static void main(String[] args) {
        Creator creator = new ConcreteCreator();
        Product product = creator.createProduct(ConcreteProduct1.class);
        /**
         * 继续业务处理
         */
    }
}

工厂方法模式的应用

工厂方法模式的优点

首先，良好的封装性，代码结构清晰。一个对象创建是有条件约束的，如果一个调用者需要一个具体的产品对象，只要知道这个产品的类名（或约束字符串）就可以了，不用知道创建对象的艰辛过程，降低模块间的耦合。

其次，工厂方法模式的扩展性非常优秀。在增加产品类的情况下，只要适当地修改具体的工厂类或扩展一个工厂类，就可以完成“拥抱变化”。

再次，屏蔽产品类。这一特点非常重要，产品类的实现如何变化，调用者都不需要关心，它只需要关心产品的接口，只要接口保持不变，系统的上层模块就不需要发生变化。以为产品类的实例化工作是由工厂类负责的，一个产品对象具体由哪一个产品生成是由工厂类决定的。数据库开发中，大家应该能够深刻体会到工厂方法模式的好处：如果使用JDBC链接数据库，数据库从Mysql切换到Oracle，需要改动的地方就是切换一下驱动名称（前提条件是SQL语句是标准语句），其他的都不需要修改，这就是工厂方法模式灵活性的一个直接案例。

最后，工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类，其他的实现类都不关心，复合迪米特法则，我们不需要的就不要去交流；也符合依赖倒置原则，只依赖产品的抽象；当然也符合里氏替换原则，使用产品子类替换产品父类。

工厂方法的使用场景

首先，工厂方法是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要慎重地考虑是否要增加一个工厂进行管理，增加代码的复杂度。

其次，需要灵活的、可扩展的框架时，可以考虑采用工厂方法模式。万物皆对象，那万物也就皆是产品类，例如需要设计一个连接邮件服务器的框架，有三种协议可供选择：POP3、IMAP、HTTP，我们就可以把这三种连接方式作为产品类，定义一个接口如IConnectMail，然后定义对邮件的操作方法，用不同的方法实现三个具体的产品类（也就是连接方式）。如此设计，可以做到完美的扩展，如某些邮件服务器提供了WebService接口，我们只需要添加一个产品类就可以了。

再次，工厂方法模式可以用在异构项目中，例如通过WebService与一个非Java的项目交互，虽然WebService号称是可以做到异构系统的同构化，但在实际的开发中，还是会碰到很多问题，如类型问题、WSDL文件的支持问题，等等。从WSDL中产生的对象都认为是一个产品，然后由一个具体的工厂进行管理，减少对外围系统的耦合。

最后，可以使用在测试驱动开发的框架下。例如，测试一个类A，就需要把与类A有关联关系的类B也同时产生出来，我们可以使用工厂方法模式把类B虚拟出来，避免类A与类B的耦合。

工厂方法模式的扩展

工厂方法模式有很多扩展，而且与其他设计模式结合使用威力更大，下面将介绍4中扩展。

缩小为简单工厂模式

我们这样考虑一个问题：一个模块仅需要一个工厂类，没有必要把它产生出来，使用静态的方法就可以了。

该模式是工厂方法模式的弱化，因为简单，所以称为简单工厂模式（Simple Factory Pattern），也叫静态工厂模式。在实际项目中，采用该方法的案例还是比较多的，其缺点是工厂的扩展比较困难，不符合开闭原则，但它仍然是一个非常使用的设计模式。

public class SimpleFactory {
    public static <T extends Product> T createProduct(Class<T> c){
        Product product = null;
        try {
            product = (Product) Class.forName(c.getName()).newInstance();
        } catch (Exception e) {
            // 异常处理
        }
        return (T)product;
    }
}

升级为多个工厂类

当我们在做一个比较复杂的项目时，经常会遇到初始化一个对象很耗费精力的情况，所有的产品类都放到一个工厂方法中进行初始化会使代码结构不清晰。例如，一个产品有5个具体实现，每个实现类的初始化（不仅仅是new，初始化包括new一个对象，并对对象设置一定的初始值）方法都不相同，如果写在一个工厂方法中，势必会导致该方法巨大无比，那怎么办？

考虑需要结构清晰，我们就为每一个产品定义一个创造者，然后由调用者自己去选择与哪个工厂方法关联。

public abstract class AbstractHumanFactory{
    /*
     * 抽象方法中已经不在需要传递相关参数了，因为每一个具体的工厂都已经非常明确自己的职责：
     * 创建自己负责的产品类对象。
     */
    public abstract Human createHuman();
}

public class BlackHumanFactory extends AbstractHumanFactory {
    public Human createHuman() {
        return new BlackHuman();
    }
}

public class YellowHumanFactory extends AbstractHumanFactory {
    public Human createHuman() {
        return new YellowHuman();
    }
}

public class WhiteHumanFactory extends AbstractHumanFactory {
    public Human createHuman() {
        return new WhiteHuman();
    }
}

让我们回顾一下，每个产品类都对应一个创建类，好处就是创建类的职责清晰，而且结构简单，但是给可扩展性和可维护性带来了一定的影响。如果要扩展一个产品类，就需要建立一个相应的工厂类，这样就增加了扩展的难度。因为工厂类和产品类的数量相同，维护时需要考虑两个对象之间的关系。

当然，在复杂的应用中一般采用多工厂的方法，然后再增加一个协调类，避免调用者与各个子工厂交流，协调类的作用是封装子工厂类，对高层模块提供统一的访问接口。

代替单例模式

单例模式的核心要求就是在内存中只有一个对象，通过工厂方法模式也可以只在内存中生产一个对象。

// 单例类
public class Singleton {
    private Singleton() {}
    public void doSomething() {
        // 业务逻辑
    }
}

public class SingletonFactory {
    private static Singleton singleton = null;
    static {
        try {
            Class cl = Class.forName(Singleton.class.getName());
            // 获得无参构造
            Constructor constructor = cl.getDeclaredConstructor();
            // 设置无参构造是可访问的
            constructor.setAccessible(true);
            // 产生一个实例对象
            singleton = (Singleton) constructor.newInstance();
        } catch (Exception e) {
            // 异常处理
        }
    }
    
    public static Singleton getSingleton() {
        return singleton;
    }
}

延迟初始化

延迟初始化（Lazy initialization）：一个对象被消费完毕后，并不立刻释放，工厂类保持其初始状态，等待再次使用。延迟初始化是工厂方法模式的一个扩展应用

public class ProductFactory {
    private static final Map<String,Product> prMap = new HashMap(16);
    public static synchronized Product createProduct(String type) throws Exception {
        Product product = null;
        if(prMap.containsKey(type)) {
            product = prMap.get(type);
        } else {
            if(type.equals("Product0")) {
                product = new ConcreteProduct0();
            }
            if(type.equals("Product1")) {
                product = new ConcreteProduct1();
            }
            prMap.put(type,product);
        }
        return product;
    }
}

代码比较简单，通过定义一个Map容器，容纳所有产生的对象，如果在Map容器已有的对象，则直接取出来返回；如果没有，则根据需要的类型产生一个对象并放入到Map容器中，以方便下次调用。

延迟加载框架是可以扩展的，例如限制某一个产品类的额最大实例化数量，可以通过判断Map中已有的对象的数量来实现，这样的处理是非常有意义的。例如JDBC连接数据库，都会要求设置一个MaxConnections最大连接数量，该数量就是内存中最大实例化的数量。

延迟加载还可以用在对象初始化比较复杂的情况下，例如硬件访问，涉及多方面交互，则可以通过延迟加载降低对象的产生和销毁带来的复杂性。

最佳实践

工厂方法模式在项目中使用的非常频繁，以至于很多代码中都包含工厂方法模式。该模式几乎尽人皆知，但不是每个人都用的好。孰能生巧，熟练掌握该模式，多思考工厂方法如何应用，而且工厂方法模式还可以与其他模式混合使用（例如模板方法模式、单例模式、原型模式等），变化出无穷的优秀设计，这也正是软件设计和开发的乐趣所在。