模板方法模式
模板方法通过名字大概就可以猜出来其含义,即有一个方法,它是模板
方法好理解,那就剩下一个问题就是模板。那么在编程中什么场景下需要模板呢?我们来看下面的场景
场景描述:将一个东西放如冰箱总共分几步
1)打开冰箱
2)把东西放入冰箱
3)关上冰箱
在整个过程中它的处理流程不变,此时我们可以将整个过程看为一个模板,因为所有的东西想放入冰箱都需要遵循这个流程。
就不画类图了,此设计模式并没有复杂的类体系
代码实现如下
program TemplateMethod;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils;
type
{ 定义冰箱类 }
TRefrigerator = class
Protected
{ 打开冰箱 }
procedure Open(); virtual; abstract;
{ 存放东西 }
procedure Deposit(); virtual; abstract;
{ 关闭冰箱 }
procedure Close(); virtual; abstract;
{ 模板方法,向冰箱中存放东西 }
procedure DepositToRefrigerator();
end;
{ 定义冰箱的子类海尔冰箱 }
THaierRefrigerator = class(TRefrigerator)
procedure Open(); override;
procedure Deposit(); override;
procedure Close(); override;
end;
{ TRefrigerator }
procedure TRefrigerator.DepositToRefrigerator;
begin
// 存放东西的整体流程
Open();
Deposit();
Close()
end;
{ THaierRefrigerator }
procedure THaierRefrigerator.Close;
begin
Writeln('Haier冰箱关闭');
end;
procedure THaierRefrigerator.Deposit;
begin
Writeln('Haier冰箱存放');
end;
procedure THaierRefrigerator.Open;
begin
Writeln('Haier冰箱打开');
end;
begin
//创建子类对象
var
HaierRefrigerator := THaierRefrigerator.Create();
//调用模板方法
HaierRefrigerator.DepositToRefrigerator();
Readln;
end.
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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
# 总结一下
不变部分封装到父类中实现,可变部分算法由子类继承实现,便于子类继续扩展。
在父类中提取了公共的部分代码,便于代码复用。
每个不同的实现都需要定义一个子类,这会导致类的个数增加。
父类中的抽象方法由子类实现,子类执行的结果会影响父类的结果,这导致一种反向的控制结构,提高了代码阅读的难度。
当父类修改了抽象方法后,所有的子类都需要修改
以上便是我对对模板方法设计模式的理解。世界上没有十全十美的东西有的只是合适和不合适