工厂方法模式(Factory Method)

First Post:

Last Update:

工厂方法模式(Factory Method)

工厂方法模式(Factory Method),定义了一个用于创建对象的接口,让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。

工厂方法模式结构图

例子

工厂方法模式代码结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
先构建一个工厂接口 IFactory
interface IFactory
{
operation CreateOperation();
}

然后各个计算方法均各建一个具体工厂类取实现该接口
class AddFactory : IFactory
{//加法类工厂
public operation CreateOperation()
{
retrun new OperationAdd();
}
}

class SubFactory : IFactory
{//减法类工厂
public operation CreateOperation()
{
retrun new OperationSub();
}
}

class MulFactory : IFactory
{//乘法类工厂
public operation CreateOperation()
{
retrun new OperationMul();
}
}

class DivFactory : IFactory
{//除法类工厂
public operation CreateOperation()
{
retrun new OperationDiv();
}
}

//客户端调用:
IFactory operFactory = new AddFactory();
Operation oper = operFactory.CreateOperation( );
oper.NumA = 1;
oper.NumB = 2;
double result = oper.GetResult( );

简单工厂和工厂方法模式区别所在:

  • 要添加功能类时
    简单工厂需要先添加一个功能类,再到工厂中添加注册case语句。
    而工厂方法需要添加一个工厂类继承工厂接口,再去更改客户端。看起来好似不但没有简化难度,反而增加了很多的类和方法,复杂度更高了。
    可以想到,修改简单工厂违背了“开闭原则”,而工厂方法不会。

  • 简单工厂模式最大的优点在于工厂类中包含了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。

工厂方法模式是为了符合“开闭原则”的精神而设计的。

既然工厂类和分支耦合,那么就对它下手, 根据依赖倒置原则,将工厂类抽象出一个接口。

这个接口只有一个方法,就是创建抽象产品的工厂方法。

然后所有生产具体对象的工厂,都要去实现这个接口。

这样——简单工厂就被拆成了一个工厂抽象接口和多个生成具体对象的工厂

要添加功能时,只需要增加此功能的产品类和相应的工厂类即可。


可以注意到:

工厂方法模式对于整个工厂和产品体系都没有修改的变化,只有拓展的变化。

工厂方法模式实现时,客户端需要决定实例化哪一个工厂来实现运算类,选择判断的问题还是存在的,也就是说工厂方法把简单工厂的内部逻辑判断移到了客户端代码进行。需要加功能时,简单工厂需要改工厂类,而工厂方法需要修改客户端。

这样还是没有避免修改客户端的弊端——“最佳做法”

利用“反射”可以解决避免分支判断的问题。

游戏开发中的工厂模式——对象池(Object Pool)

使用工厂模式创建对象,可以对对象进行统一的创建、初始化等操作,便于对对象做统一的管理,比如对频繁创建销毁的对象增加内存池。