1.前言
在上文提到的最易懂的设计模式系列解析:简单工厂模式,发现简单工厂模式存在一系列问题:
- 工厂类集中了所有实例(产品)的创建逻辑,一旦这个工厂不能正常工作,整个系统都会受到影响;
- 违背“开放——关闭原则”,一旦添加新产品就不得不修改工厂类的逻辑,这样就会造成工厂逻辑过于复杂;
- 简单工厂模式由于使用了静态工厂方法,静态方法不能被继承和重写,会造成工厂角色无法形成基于继承的等级结构。
为了解决上述的问题,我们又使用了一种新的设计模式:工厂方法模式。
2.介绍
2.1.定义
工厂方法模式,又称多态工厂模式、虚拟构造器模式,通过定义工厂父类负责定义创建对象的公共接口,而子类则负责生成具体的对象。
将类的实例化(具体产品的创建)延迟到工厂类的子类(具体工厂)中完成,即由子类来决定应该实例化(创建)哪一个类。
2.2.解决的问题
解决简单工厂模式的缺点:
工厂方法模式把具体产品的创建推迟到工厂类的子类(具体工厂)中,此时工厂类不再负责所有产品的创建,而只是给出具体工厂必须实现的接口,这样工厂方法模式在添加新产品的时候就不修改工厂类逻辑而是添加新的工厂子类,符合“开放——封闭原则”
2.3.结构与模式
工厂方法模式由抽象工厂、具体工厂、抽象产品和具体产品等4个要素构成。
- 抽象工厂(Abstract Factory):提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法 newProduct()来创建产品。
- 具体工厂(ConcreteFactory):主要是实现抽象工厂中的抽象方法,完成具体产品的创建。
- 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能。
- 具体产品(ConcreteProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应。
工厂方法模式结构图:

2.4.代码实现
// 产品抽象接口
public interface Product {
void show();
}
// 具体产品1
public class ConcreteProduct1 implements Product {
@Override
public void show() {
System.out.println("this is ConcreteProduct1");
}
}
// 具体产品2
public class ConcreteProduct2 implements Product {
@Override
public void show() {
System.out.println("this is ConcreteProduct2");
}
}
// 抽象工厂接口
public interface Factory {
Product makeProduct();
}
// 具体工厂1
public class ConcreteFactory1 implements Factory{
@Override
public Product makeProduct() {
return new ConcreteProduct1();
}
}
// 具体工厂2
public class ConcreteFactory2 implements Factory {
@Override
public Product makeProduct() {
return new ConcreteProduct2();
}
}
客户端代码
@Test
public void test(){
Factory f1 = new ConcreteFactory1();
Product p1 = f1.makeProduct();
p1.show();
Factory f2 = new ConcreteFactory2();
Product p2 = f2.makeProduct();
p2.show();
}
结果输出
this is ConcreteProduct1
this is ConcreteProduct2
3.应用场景
3.1. 优缺点
3.1.1.优点
- 更符合开-闭原则
新增一种产品时,只需要增加相应的具体产品类和相应的工厂子类即可 - 符合单一职责原则
每个具体工厂类只负责创建对应的产品 - 不使用静态工厂方法,可以形成基于继承的等级结构。
总结:工厂模式可以说是简单工厂模式的进一步抽象和拓展,在保留了简单工厂的封装优点的同时,让扩展变得简单,让继承变得可行,增加了多态性的体现。
3.1.2.缺点
- 添加新产品时,除了增加新产品类外,还要提供与之对应的具体工厂类,系统类的个数将成对增加,在一定程度上增加了系统的复杂度;同时,有更多的类需要编译和运行,会给系统带来一些额外的开销;
- 由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度,且在实现时可能需要用到DOM、反射等技术,增加了系统的实现难度。
- 虽然保证了工厂方法内的对修改关闭,但对于使用工厂方法的类,如果要更换另外一种产品,仍然需要修改实例化的具体工厂类;
- 一个具体工厂只能创建一种具体产品
3.2.应用场景
- 当一个类不知道它所需要的对象的类时
在工厂方法模式中,客户端不需要知道具体产品类的类名,只需要知道所对应的工厂即可; - 当一个类希望通过其子类来指定创建对象时
在工厂方法模式中,对于抽象工厂类只需要提供一个创建产品的接口,而由其子类来确定具体要创建的对象,利用面向对象的多态性和里氏代换原则,在程序运行时,子类对象将覆盖父类对象,从而使得系统更容易扩展。 - 将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定,可将具体工厂类的类名存储在配置文件或数据库中。
本文介绍了工厂方法模式,如何解决简单工厂模式的问题,包括更灵活的扩展性、遵循开闭原则和单一职责原则。通过抽象工厂、具体工厂和产品角色,展示了模式结构及代码实现,并讨论了其优缺点和典型应用场景,如动态产品选择和模块化扩展。
642

被折叠的 条评论
为什么被折叠?



