设计模式（18）:状态模式

本章节我们来学习状态模式，什么是状态，世间万事万物都有状态说法，状态是人或事物表现出来的形态。这个词大概的意思就是这样，状态在生活中随处都有，比如水的状态有固态（冰），液态、气态等状态，有比如汽车有运行状态、停止状态、故障状态等。。。接下来我们来看看状态模式的定义：**当一 个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类，状态模式的核心是封装，状态的变更引起了行为的变更，从外部看起来就好像这个对象对应的类发生了改 变一样。**这句话什么意思呢？其实是再说，对象的行为跟其状态密切相关，举例说明，如汽车在故障的状态下不能运行这就是 运行这个行为跟故障状态的密切关系。接下来我们看看状态模式的通用类图：

● State——抽象状态角色 接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。
● ConcreteState——具体状态角色 每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗地说，就是本状态下要做 的事情，以及本状态如何过渡到其他状态。
● Context——环境角色 定义客户端需要的接口，并且负责具体状态的切换。

伪代码：
status：

ConcreteState1：

ConcreteState2：

Context：

client：

案例：我们使用电梯来举例子，我们先看看电梯的状态跟行为的关系：

此案例类图如下：

代码结构：

AbstractLiftState：

CloseDoorState：

OpenDoorState：

RunState：

StopState：

Context：

Test:

总结：上述案例有一个问题，就是比如当当前状态为开门状态的时候，我再去执行开门这个操作的时候，是可以成功的，但是有点时候我们可能不想让他成功，是想让它返回 ”已经是开门状态了，不能再开门“ 如果这种需求的话，需要在使用Context类的时候，就是在本案例的Test类中加入此业务逻辑。

状态模式的优点：
● 结构清晰 避免了过多的switch…case或者if…else语句的使用，避免了程序的复杂性,提高系统的可维护性。
● 遵循设计原则 很好地体现了开闭原则和单一职责原则，每个状态都是一个子类，你要增加状态就要增加子类，你要修改 状态，你只修改一个子类就可以了。
● 封装性非常好 这也是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态 和行为的变换

状态模式的缺点：
状态模式既然有优点，那当然有缺点了。但只有一个缺点，子类会太多，也就是类膨胀。如果一个事物有 很多个状态也不稀奇，如果完全使用状态模式就会有太多的子类，不好管理，这个需要大家在项目中自己衡 量。其实有很多方式可以解决这个状态问题，如在数据库中建立一个状态表，然后根据状态执行相应的操作， 这个也不复杂，看大家的习惯和嗜好了

状态模式的使用场景：
● 行为随状态改变而改变的场景 这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这 种情况下需要考虑使用状态模式。
● 条件、分支判断语句的替代者 在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地 避免这一问题，它通过扩展子类实现了条件的判断处理。