设计模式--工厂方法模式（Factory Method Pattern）

定义

定义一个用于建立对象的接口，让子类决定实例化那个类。

使用场景

• 在任何须要生成复杂对象的地方，均可以使用工厂方法模式。
• 客户端只知道传入工厂类的参数，对于如何建立对象不关心：客户端既不须要关心建立细节，甚至连类名都不须要记住，只须要知道类型所对应的参数

UML类图

简单工厂：

工厂方法：

  工厂方法模式是简单工厂模式的进一步抽象和推广。因为使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优势，并且克服了它的缺点。在工厂方法模式中，核心的工厂类再也不负责全部产品的建立，而是将具体建立工做交给子类去作。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责哪个产品类被实例化这种细节，这使得工厂方法模式能够容许系统在不修改工厂角色的状况下引进新产品。

使用反射实现工厂方法模式：

public abstract class Factory {
    public abstract <T extends Product> T createProduct(Class<T> clz);
}

public class ConcreteFactory extends Factory {

    @Override
    public <T extends Product> T createProduct(Class<T> clz) {
        Product p = null;
        try {
            p = (Product) Class.from(clz.getName()).newInstance();
        } catch(Exception e) {
       }
        return (T) p;
    }
}
复制代码

优势

• 在工厂方法模式中，工厂方法用来建立客户所须要的产品，同时还向客户隐藏了哪一种具体产品类将被实例化这一细节，用户只须要关心所需产品对应的工厂，无须关心建立细节，甚至无须知道具体产品类的类名。
• 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它可以使工厂能够自主肯定建立何种产品对象，而如何建立这个对象的细节则彻底封装在具体工厂内部。工厂方法模式之因此又被称为多态工厂模式，是由于全部的具体工厂类都具备同一抽象父类。
• 使用工厂方法模式的另外一个优势是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其余的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就能够了。这样，系统的可扩展性也就变得很是好，彻底符合“开闭原则”。

缺点

• 在添加新产品时，须要编写新的具体产品类，并且还要提供与之对应的具体工厂类，系统中类的个数将成对增长，在必定程度上增长了系统的复杂度，有更多的类须要编译和运行，会给系统带来一些额外的开销。
• 因为考虑到系统的可扩展性，须要引入抽象层，在客户端代码中均使用抽象层进行定义，增长了系统的抽象性和理解难度，且在实现时可能须要用到DOM(Document Object Model)、反射等技术，增长了系统的实现难度。