本文主要是介绍设计模式之禅——状态模式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
我们每个人都乘过电梯,电梯的动作:开门、关门、运行、停止。
现在我们用程序来实现一个电梯的动作,先看类图设计,如图所示
现在看一下代码
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
代码非常简单,但是这个程序是有问题的。
————————————————————
1、电梯门可以打开,但不是随时都可以打开,电梯运行的时候不能突然开门。
2、电梯也不会出现停止了但是不开门的情况。
————————————————————
所以我们可以看出,电梯的这四个动作的执行都有前置条件,具体点说就是在特定状态下才能做做特定的事。
接下来我们分析一下电梯有哪些特定的状态
-
敞门状态
按了电梯上下按钮,电梯门开,这中间大概有10秒的时间,那就是敞门状态。在这个状态下电梯只能做的动作就是关门动作。 -
闭门状态
电梯门关闭了,在这个状态下,可以进行的动作是:开门(我不想坐电梯了)、停止(忘记按路层号了)、运行。 - 运行状态
电梯正在跑,上下窜,在这个状态下,电梯能做的是停止 - 停止状态
电梯停止不动,在这个状态下,电梯有两个可选动作:继续运行和开门动作。
现在重新进行设计,类图如下:
—————————————————————————————
在接口中添加了标识变量,类LIft中的open、close等方法带有了逻辑判断。
—————————————————————————————
代码如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 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
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 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
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
好了,改过的代码已经实现了简单的逻辑控制。但是它好像还是有不少问题。
————————————————————————————
-
电梯实现类Lift有点长
-长的原因是因为我们在程序中使用了大量的switch…case这样的判断(if…else也是一样) -
拓展类非常差,电梯还有两个状态,通电状态,断电状态,你要是在程序增加这两个方法,你看看Open()、Close()、Run()、Stop()这四个方法都要增加判断条件,也就是说在switch判断体中还要增加case项、这与开闭原则相违背。
- 非常规状态无法实现
考虑电梯故障等情况就更麻烦了…
—————————————————————————————
我们已经发现程序中有以上问题,我们怎么来修改呢?
刚刚我们是从电梯的方法以及这些方法执行的条件去分析,现在我们换个角度来看问题。我们来想,电梯在具有这些状态的时候能够做什么实行,也就是说电梯在处于某个具体状态时,我们来思考 这个状态是由什么动作出发触发的而产生的,以及在这个状态下电梯还能做什么事情。例如,电器在停止状态时,我们来思考两个问题:
—————————————————————————————
- 停止状态是怎么来的,那当然是由于电梯执行了stop方法而来的。
-
- 在停止状态下,电梯还能做什么动作?继续运行?开门?当然都可以了
—————————————————————————————
我们再来分析其他三个状态,也都是一样的结果,我们只要实现电梯在一个状态下的两个任务模型就可以了:这个状态是如何产生的,以及在这个状态下还能做什么其他动作(也就是这个状态怎么过度到其他状态),既然我们以状态作为参考模型,那我们先定义电梯的状态接口,类图如下
代码如下
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 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
- 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
- 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
- 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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
把逻辑放到没一个状态内,然后用context整合,做到添加状态的时候也不需要修改原来的代码。
状态模式的定义:当一个对象内在状态改变时允许其改变行为,这个对象 看起来像改变了其类。
状态模式的核心是封装,状态的变更引起了行为的变更,从外部看起来就好像这个对象对应的类发生了改变一样。
状态模式的角色主要有三个:抽象状态角色,具体状态 角色,环境角色
状态模式的优点:
- 结构清晰,避免了过多的switch…case或者if…else语句的使用
- 遵循设计原则,很多地体现了开闭原则和单一职责原则,每个状态都是一个子类。
-
封装性比较好
状态模式的缺点:
- 类膨胀
状态模式的使用场景
- 行为随状态改变而改变
-
条件、分支判断语句的替代者
注意事项
-
子类最好不要超过5个
这篇关于设计模式之禅——状态模式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!