情景分析:现实中的工厂大家应该都有概念,它就对应了简单工厂设计模式,即:一个工厂只有一套特定的生产产品的方法和设备。
而工厂方法模式就是为了解决 ” 当一个工厂要生产新的产品时,不得不更换厂子里的设备和生产方法" 的问题。
模式动机:考虑这样一个系统,按钮工厂类可以返回一个具体的按钮实例,如圆形按钮、矩形按钮、菱形按钮等。在这个系统中,如果需要增加一种新类型的按钮,如椭圆形按钮,那么除了增加一个新的具体产品类之外,还需要修改工厂类的代码,这就使得整个设计在一定程度上违反了“开闭原则”。 现在对该系统进行修改,不再设计一个按钮工厂类来统一负责所有产品的创建,而是将具体按钮的创建过程交给专门的工厂子类去完成,我们先定义一个抽象的按钮工厂类,再定义具体的工厂类来生成圆形按钮、矩形按钮、菱形按钮等,它们实现在抽象按钮工厂类中定义的方法。这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新的产品,如果出现新的按钮类型,只需要为这种新类型的按钮创建一个具体的工厂类就可以获得该新按钮的实例,这一特点无疑使得工厂方法模式具有超越简单工厂模式的优越性,更加符合“开闭原则”。
模式定义:工厂方法模式(Factory Method Pattern)又称为工厂模式,也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式,它属于类创建型模式。
在工厂方法模式中,工厂父类负责定义创建产品对象的公共接口,而工厂子类则负责生成具体的产品对象,这样做的目的是将产品类的实例化操作延迟到工厂子类中完成,即通过工厂子类来确定究竟应该实例化哪一个具体产品类。
模式结构:
模式分析:抽象工厂类代码
public abstract class PayMethodFactory
{
public abstract AbstractPay getPayMethod();
}
具体工厂类代码
public class CashPayFactory extends PayMethodFactory
{
public AbstractPay getPayMethod()
{
return new CashPay();
}
}
客户类代码片段
PayMethodFactory factory; //抽象工厂类对象
AbstractPay payMethod; //抽象产品类对象
factory=new CashPayFactory(); //创建实体工厂类 并赋给抽象工厂对象
payMethod =factory.getPayMethod(); //抽象工厂对象 调用 实体工厂生产函数
payMethod.pay();