又在温习设计模式咯,所以把学习的经历写下来.....
我们希望建立一个银行系统,但银行系统应具有一些业务,诸如存款、取款、转账等,通过对这些业务进行抽象,得到一个业务接口:IOperation,该接口包含一个业务处理的抽象方法operation,如下所示:
1
interface IOperation
2
{
3
void operation();
4
}

2

3

4

通过该接口实现各个银行功能类:
1
/// <summary>
2
/// 存款业务处理类
3
/// </summary>
4
class SavingBox:IOperation
5
{
6
public void operation()
7
{
8
Console.WriteLine("You are saving!");
9
}
10
}
11
/// <summary>
12
/// 取款业务处理类
13
/// </summary>
14
class OutingBox : IOperation
15
{
16
public void operation()
17
{
18
Console.WriteLine("You are outing!");
19
}
20
}
21
/// <summary>
22
/// 转账业务处理类
23
/// </summary>
24
class TurningBox : IOperation
25
{
26
public void operation()
27
{
28
Console.WriteLine("You are turning!");
29
}
30
}

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

OK,一个简单的银行业务系统就初具规模,但是当用户进入这个系统时,系统是如何判定到底用户是存款、取款还是转账,也就是系统应该初始化哪个业务处理流程响应用户需求?我们建立一个抽象工厂类,这个抽象工厂类的功能在于通过用户给定的信息来决定初始化哪一个业务类:
1
class SimpleFactory
2
{
3
public static IOperation getOpertion(string operation)
4
{
5
IOperation opera;
6
switch (operation)
7
{
8
case "turn":
9
opera = new TurningBox();
10
break;
11
case "out":
12
opera = new OutingBox();
13
break;
14
default:
15
opera = new SavingBox();
16
break;
17
}
18
return opera;
19
}
20
}

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

现在可以写主程序了,假设用户是一个转账用户,通过工厂类产生业务类,调用业务类的operation方法处理用户需求。
1
class Program
2
{
3
static void Main(string[] args)
4
{
5
IOperation opera = SimpleFactory.getOpertion("turn");
6
opera.operation();
7
Console.ReadKey();
8
}
9
}

2

3

4

5

6

7

8

9

简单工厂的特点(载自网络):
工厂类是整个模式的关键所在。它包含必要的判断逻辑,能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例,而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
但是,简单工厂模式的缺点也正体现在其工厂类上,由于工厂类集中了所有实例的创建逻辑,所以“高内聚”方面做的并不好。另外,当系统中的具体产品类不断增多时,可能会出现要求工厂类也要做相应的修改,扩展性并不很好。