再说设计模式-工厂方法模式

定义

工厂方法模式使用的频率非常高，在我们日常的开发中总能见到它的身影。其定义如下：

Define an interface for creating an object, but let subclasses decide which class to instantiate.
定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使用一个类的实例化延迟到其子类。

工厂方法模式的通用类图如下：

工厂方法模式的通用类图

在工厂方法模式中，抽象产品类Product负责定义产品的共性，实现了对事物最抽象的定义；Creator为抽象创建类，也就是抽象工厂，具体如何创建产品类是由具体的实现工厂ConcreteCreator完成的。

通用框架

工厂方法模式的变种较多，我们来看一个比较实用的通用源码。
抽象产品类：

public abstract class Product {
  // 产品类的公共方法
  public void bizComm() {
    // 业务逻辑处理
  }
  // 抽象方法
  public abstract void methodXXX();
}

具体产品类：

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

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

抽象工厂类

public abstract class Creator {
  // 创建一个产品对象，其输入参数类型可以自行设置，
  // 通常为String, Enum, Class等，当然也可以为空
  public abstract  T createProduct(Class c);
}

具体工厂类

public class ConcreteCreator extends Creator {
  public  T createProduct(Class 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);
   // 其他业务处理
 }
}

优点

首先，良好的封装性，代码结构清晰，一个对象的创建是有条件约束的，如一个调用者需要一个具体的产品对象，只要知道这个产品的类名就可以了，不用知道创建对象的艰辛过程，降低模块间的耦合。
其次，工厂方法模式的扩展性非常优秀，在增加产品类的情况下，只要适当地修改具体的工厂类或扩展一个工厂类，就可以完成“拥抱变化”。
再次，屏蔽了产品类。产品类的实现如何变化，调用者都不需要关心，它只需要关心产品的接口，只要接口保持不变，系统中的上层模块就不要发生变化。
最后，工厂方法模式是典型的解耦框架。高层模块只需要知道产品的抽象类，其他实现类都不用关心，符合迪米特法则，我不需要的就不要去交流；也符合依赖倒置原则，只依赖产品类的抽象；当然也符合里氏替换原则，使用产品子类替换产品父类。

扩展

再说-工厂方法模式扩展