设计模式：工厂方法

工厂方法模式的定义

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

工厂方法模式的通用类图如图所示。

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

/**
 * 抽象产品类
 */
public abstract class Product {
    //产品类的公共方法
    public void method1(){
    //业务逻辑处理
    }
    //抽象方法
    public abstract void method2();
}
/**
 * 具体产品类
 */
public class ConcreteProduct1 extends Product {
    public void method2() {
        //业务逻辑处理
    }
}
public class ConcreteProduct2 extends Product {
    public void method2() {
        //业务逻辑处理
    }
}
           

具体的产品类可以有多个， 都继承于抽象产品类。

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;
    }
}
           

具体如何产生一个产品的对象， 是由具体的工厂类实现的

工厂方法模式的优点

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