工厂方法模式是一种创建型设计模式,又称工厂模式、多态工厂模式和虚拟构造器模式,通过定义工厂父类负责定义创建对象的公共接口,而子类则负责生成具体的对象。 将类的实例化(具体产品的创建)延迟到工厂类的子类(具体工厂)中完成,即由子类来决定应该实例化(创建)哪一个类。
解决的问题: 工厂一旦需要生产新产品就需要修改工厂类的方法逻辑,违背了“开放 - 关闭原则
- 简单工厂模式的缺点
- 之所以可以解决简单工厂的问题,是因为工厂方法模式把具体产品的创建推迟到工厂类的子类(具体工厂)中,此时工厂类不再负责所有产品的创建,而只是给出具体工厂必须实现的接口,这样工厂方法模式在添加新产品的时候就不修改工厂类逻辑而是添加新的工厂子类,符合开放封闭原则,克服了简单工厂模式中缺点。
1、模式原理
1.1 UML类图
image.png1.2 模式的组成
组成(角色) | 关系 | 作用 |
---|---|---|
抽象产品(Product) | 具体产品的父类 | 描述具体产品的公共接口 |
具体产品(Concrete Product) | 抽象产品的子类;工厂类创建的目标类 | 描述生产的具体产品 |
抽象工厂(Creator) | 具体工厂的父类 | 描述具体工厂的公共接口 |
具体工厂(Concrete Creator) | 抽象工厂的子类;被外界调用 | 描述具体工厂;实现FactoryMethod工厂方法创建具体产品的示例 |
1.3 使用步骤
- 步骤1:创建抽象产品类,定义具体产品的公共接口;
- 步骤2:创建抽象工厂类,定义具体工厂的公共接口;
- 步骤3:创建具体产品类(继承抽象产品类),定义生产的具体产品;
- 步骤4:创建具体工厂类(继承抽象工厂类),定义创建对应具体产品示例的方法;
- 步骤5:外界通过调用具体工厂类的方法,从而创建不同具体产品类的实例。
2、实例讲解
- 背景:一个手机加工厂工厂(仅生产安卓手机);随着客户需求的变化,客户需要生产苹果手机
- 冲突:改变原有的工厂配置和变化非常困难,假设下一次客户需要再发生变化,再次改变将增大非常大的成本
- 解决方案:置办手机加工厂B来生产苹果手机(即工厂方法模式)
代码实现
步骤1:创建抽象产品类,定义具体的公共接口
public abstract class Product {
public abstract void product();
}
复制代码
步骤2:创建抽象工厂类,定义具体工厂的公共接口
public abstract class Factory {
public abstract Product FactoryMethod();
}
复制代码
步骤3:创建具体产品类(继承抽象产品类),定义生产的具体产品
public class ProductA extends Product {
@Override
public void product() {
System.out.println("生产安卓手机");
}
}
public class ProductB extends Product {
@Override
public void product() {
System.out.println("生产苹果手机");
}
}
复制代码
步骤4:创建具体工厂类(继承抽象工厂类),定义创建对应具体产品示例的方法
public class FactoryA extends Factory {
@Override
public Product FactoryMethod() {
return new ProductA();
}
}
public class FactoryB extends Factory {
@Override
public Product FactoryMethod() {
return new ProductB();
}
}
复制代码
步骤5:外界通过调用具体工厂类的方法,从而创建不同具体产品类的实例
public class FactoryPattern {
public static void main(String[] args) {
//客户A要求生产安卓手机
Factory factoryA = new FactoryA();
factoryA.FactoryMethod().product();
//客户要求生产苹果手机
Factory factoryB = new FactoryB();
factoryB.FactoryMethod().product();
}
}
结果:
生产安卓手机
生产苹果手机
复制代码
3、优缺点
3.1 优点
-
更符合开-闭原则
新增一种产品时,只需要增加相应的具体产品类和相应的工厂子类即可简单工厂模式需要修改工厂类的判断逻辑
-
符合单一职责原则
每个具体工厂类只负责创建对应的产品 简单工厂中的工厂类存在复杂的switch逻辑判断
-
不使用静态工厂方法,可以形成基于继承的等级结构。
简单工厂模式的模式类使用静态工厂方法
总结:工厂模式可以说是简单工厂模式的进一步抽象和拓展,在保留了简单工厂的封装优点的同时,让扩展变得简单,让继承变得可行,增加了多态性的体现。
3.2 缺点
- 添加新产品时,除了增加新产品类外,还要提供与之对应的具体工厂类,系统类的个数将成对增加,在一定程度上增加了系统的复杂度;同时,有更多的类需要编译和运行,会给系统带来一些额外的开销;
- 由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度,且在实现时可能需要用到DOM、反射等技术,增加了系统的实现难度。
- 虽然保证了工厂方法内的对修改关闭,但对于使用工厂方法的类,如果要更换另外一种产品,仍然需要修改实例化的具体工厂类;
- 一个具体工厂只能创建一种具体产品
4、应用场景
-
当一个类不知道它所需要的对象的类时
在工厂方法模式中,客户端不需要知道具体产品类的类名,只需要知道所对应的工厂即可;
-
当一个类希望通过其子类来指定创建对象时
在工厂方法模式中,对于抽象工厂类只需要提供一个创建产品的接口,而由其子类来确定具体要 创建的对象,利用面向对象的多态性和里氏代换原则,在程序运行时,子类对象将覆盖父类对 象,从而使得系统更容易扩展。
-
将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定,可将具体工厂类的类名存储在配置文件或数据库中。
作者:YaDe
链接:https://juejin.cn/post/6906422634767253512
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
网友评论