设计模式实战-状态模式(State Pattern)（上）

1 前言

有时一个对象的行为取决于一或多个动态变化的属性（状态），这样的对象称为有状态的(stateful)对象，其对象状态是从事先定义好的一系列值中取出。当这样的对象与外部事件产生互动时，内部状态就会改变，对象行为也随之变化。

在UML中可以使用状态图来描述对象状态的变化。在状态模式中，创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。

2 定义

该模式中，类的行为基于其状态改变。即允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。

3 架构

Context-环境类

拥有状态的对象，环境类有时可以充当状态管理器(State Manager)，在环境类中对状态进行切换操作。

State-抽象状态类

可以是抽象类，也可是接口，不同状态类就是继承这个父类的不同子类，状态类的产生是由于环境类存在多个状态，同时还满足：这些状态经常需要切换，在不同状态下对象行为不同。

ConcreteState-具体状态类

4 意义

解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。

状态模式的关键是引入了一个抽象类来专门表示对象的状态 - 抽象状态类。而对象的每种具体状态类都继承该类，并在不同具体状态类中实现不同状态的行为，包括各种状态之间的转换。

可以将不同对象下的行为单独提取出来封装在具体的状态类，使得环境类对象在其内部状态改变时可以改变它的行为，对象看起来似乎修改了它的类，而实际上是由于切换到不同的具体状态类实现的。

由于环境类可以设置为任一具体状态类，因此它针对抽象状态类进行编程，在程序运行时可以将任一具体状态类的对象设置到环境类中，从而使得环境类可以改变内部状态，并且改变行为。

5 优点

1. 封装了转换规则
2. 枚举可能的状态，在枚举状态之前需要确定状态种类
3. 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。

1. 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
2. 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

6 缺点

1. 必然增加系统类和对象的个数
2. 结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱
3. 对"开闭原则"支持不太好，对可切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码
4. 在DDD中，为所有状态创建单独的类会使系统变得复杂。对于实体状态类来说，有些行 为来自于自身，有些行为继承自抽象基类，这一方面在子类和父类之间形成紧耦合，另一方面使代码的可读性变差。但是，使用枚举则非常简单，与通过状态模式来创建标准类型相比，枚举可能是更好的方法。这里我们同时得到了两种方法的好处：

获得了一个非常简单的标准类型

又能有效地表示当前的状态