UML类图
模式定义
工厂方法模式(FACTORY METHOD)是一种常用的对象创建型设计模式,此模式的核心精神是封装类中不变的部分,提取其中个性化善变的部分为独立类,通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。
角色划分
组成(角色) | 关系 | 作用 |
---|---|---|
抽象产品(Product) | 具体产品的父类 | 描述具体产品的公共接口 |
具体产品(ConcreteProduct) | 抽象产品的子类,工厂类创建的目标类 | 描述生产的具体产品 |
抽象工厂(Factory) | 具体工厂的父类 | 描述具体工厂的公共接口 |
具体工厂(ConcreteFactory) | 抽象工厂的子类;被外界调用 描述具体工厂; | 实现FactoryMethod工厂方法创建产品的实例 |
简单实例
一个工厂需要生产一堆的产品。但是这个产品种类繁多,具体生成什么产品并不知道。所以工厂就有一个抽象方法,生产产品推脱给子类来实现。
//产品
public abstract class Product {
}
//具体产品
public class ConcreteProductA extends Product{
}
public class ConcreteProductB extends Product{
}
//工厂
public abstract class Factory {
public abstract Product createProduct();
}
//具体工厂
public class FactoryA extends Factory {
@Override
public Product createProduct() {
return new ConcreteProductA();
}
}
public class FactoryB extends Factory {
@Override
public Product createProduct() {
return new ConcreteProductB();
}
}
优缺点
优点:
更符合开-闭原则
新增一种产品时,只需要增加相应的具体产品类和相应的工厂子类即可
简单工厂模式需要修改工厂类的判断逻辑符合单一职责原则
每个具体工厂类只负责创建对应的产品不使用静态工厂方法,可以形成基于继承的等级结构。
总结:工厂模式可以说是简单工厂模式的进一步抽象和拓展,在保留了简单工厂的封装优点的同时,让扩展变得简单,让继承变得可行,增加了多态性的体现。
缺点:
添加新产品时,除了增加新产品类外,还要提供与之对应的具体工厂类,系统类的个数将成对增加,在一定程度上增加了系统的复杂度;同时,有更多的类需要编译和运行,会给系统带来一些额外的开销;
由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度,且在实现时可能需要用到DOM、反射等技术,增加了系统的实现难度。
虽然保证了工厂方法内的对修改关闭,但对于使用工厂方法的类,如果要更换另外一种产品,仍然需要修改实例化的具体工厂类;
一个具体工厂只能创建一种具体产品