从宏观的角度来讲,所有的工厂模式都致力于将new创建对象这件事都集中到某个或者某些工厂类的成员函数中去做。
前言
用游戏开发的例子来举例
在某游戏中,需要设计3中怪物,金、木、水三种怪物。
他们都继承自Monster 基类
简单工厂模式
优点:
- 结构简单
- 实现了创建怪物的代码与各个具体怪物类对象要实现的业务逻辑代码隔离
缺点:
- MonsterFactory不符合开闭原则。
- 当怪物子类增加,MonsterFactory::createMonster()中判断语句会很长
工厂方法模式
针对每种类型的怪物子类都创建一个对应的工厂类
优点:
- 符合开闭原则
- 封装变化
抽象工厂模式
新需求: 如果现在要增加一个游戏设定,不同的怪物在不同的场景下有不同的增益或减益,那该如何实现呢?
使用工厂方法模式来实现需求:
不同的类在不同的场景下都创建一个工厂类。
如果有N个怪物子类,M个场景,那么就需要N*M个工厂类!
新增1个怪物子类,就需要新增M个工厂类!
如果有这种需求变化,那么就可以采用抽象工厂模式。
抽象工厂的核心思想:如果一个工厂子类能够生产不止一种具有相同规则的对象,那么就可以有效的减少所创建的工厂子类数量。
使用抽象工厂模式来实现需求:
不同的场景下创建一个工厂类即可