# 处理对象的多种状态及其相互转换——状态模式（一）
“人有悲欢离合，月有阴晴圆缺”，包括人在内，很多事物都具有多种状态，而且在不同状态下会具有不同的行为，这些状态在特定条件下还将发生相互转换。就像水，它可以凝固成冰，也可以受热蒸发后变成水蒸汽，水可以流动，冰可以雕刻，蒸汽可以扩散。我们可以用UML状态图来描述H2O的三种状态，如图1所示：
图1 H2O的三种状态（未考虑临界点）
在软件系统中，有些对象也像水一样具有多种状态，这些状态在某些情况下能够相互转换，而且对象在不同的状态下也将具有不同的行为。为了更好地对这些具有多种状态的对象进行设计，我们可以使用一种被称之为状态模式的设计模式，本章我们将学习用于描述对象状态及其转换的状态模式。
1. 银行系统中的账户类设计
Sunny软件公司欲为某银行开发一套信用卡业务系统，银行账户(Account)是该系统的核心类之一，通过分析，Sunny软件公司开发人员发现在该系统中，账户存在三种状态，且在不同状态下账户存在不同的行为，具体说明如下：
(1) 如果账户中余额大于等于0，则账户的状态为正常状态(Normal State)，此时用户既可以向该账户存款也可以从该账户取款；
(2) 如果账户中余额小于0，并且大于-2000，则账户的状态为透支状态(Overdraft State)，此时用户既可以向该账户存款也可以从该账户取款，但需要按天计算利息；
(3) 如果账户中余额等于-2000，那么账户的状态为受限状态(Restricted State)，此时用户只能向该账户存款，不能再从中取款，同时也将按天计算利息；
(4) 根据余额的不同，以上三种状态可发生相互转换。
Sunny软件公司开发人员对银行账户类进行分析，绘制了如图2所示UML状态图：
图2 银行账户状态图
在图2中，NormalState表示正常状态，OverdraftState表示透支状态，RestrictedState表示受限状态，在这三种状态下账户对象拥有不同的行为，方法deposit()用于存款，withdraw()用于取款，computeInterest()用于计算利息，stateCheck()用于在每一次执行存款和取款操作后根据余额来判断是否要进行状态转换并实现状态转换，相同的方法在不同的状态中可能会有不同的实现。为了实现不同状态下对象的各种行为以及对象状态之间的相互转换，Sunny软件公司开发人员设计了一个较为庞大的账户类Account，其中部分代码如下所示：
```
class Account {
private String state; //状态
private int balance; //余额
......
//存款操作
public void deposit() {
//存款
stateCheck();
}
//取款操作
public void withdraw() {
if (state.equalsIgnoreCase("NormalState") || state.equalsIgnoreCase("OverdraftState ")) {
//取款
stateCheck();
}
else {
//取款受限
}
}
//计算利息操作
public void computeInterest() {
if(state.equalsIgnoreCase("OverdraftState") || state.equalsIgnoreCase("RestrictedState ")) {
//计算利息
}
}
//状态检查和转换操作
public void stateCheck() {
if (balance >= 0) {
state = "NormalState";
}
else if (balance > -2000 && balance < 0) {
state = "OverdraftState";
}
else if (balance == -2000) {
state = "RestrictedState";
}
else if (balance < -2000) {
//操作受限
}
}
......
}
```
分析上述代码，我们不难发现存在如下几个问题：
(1) 几乎每个方法中都包含状态判断语句，以判断在该状态下是否具有该方法以及在特定状态下该方法如何实现，导致代码非常冗长，可维护性较差；
(2) 拥有一个较为复杂的stateCheck()方法，包含大量的if…else if…else…语句用于进行状态转换，代码测试难度较大，且不易于维护；
(3) 系统扩展性较差，如果需要增加一种新的状态，如冻结状态（Frozen State，在该状态下既不允许存款也不允许取款），需要对原有代码进行大量修改，扩展起来非常麻烦。
为了解决这些问题，我们可以使用状态模式，在状态模式中，我们将对象在每一个状态下的行为和状态转移语句封装在一个个状态类中，通过这些状态类来分散冗长的条件转移语句，让系统具有更好的灵活性和可扩展性，状态模式可以在一定程度上解决上述问题。
- Introduction
- 基础知识
- 设计模式概述
- 从招式与内功谈起——设计模式概述（一）
- 从招式与内功谈起——设计模式概述（二）
- 从招式与内功谈起——设计模式概述（三）
- 面向对象设计原则
- 面向对象设计原则之单一职责原则
- 面向对象设计原则之开闭原则
- 面向对象设计原则之里氏代换原则
- 面向对象设计原则之依赖倒转原则
- 面向对象设计原则之接口隔离原则
- 面向对象设计原则之合成复用原则
- 面向对象设计原则之迪米特法则
- 六个创建型模式
- 简单工厂模式-Simple Factory Pattern
- 工厂三兄弟之简单工厂模式（一）
- 工厂三兄弟之简单工厂模式（二）
- 工厂三兄弟之简单工厂模式（三）
- 工厂三兄弟之简单工厂模式（四）
- 工厂方法模式-Factory Method Pattern
- 工厂三兄弟之工厂方法模式（一）
- 工厂三兄弟之工厂方法模式（二）
- 工厂三兄弟之工厂方法模式（三）
- 工厂三兄弟之工厂方法模式（四）
- 抽象工厂模式-Abstract Factory Pattern
- 工厂三兄弟之抽象工厂模式（一）
- 工厂三兄弟之抽象工厂模式（二）
- 工厂三兄弟之抽象工厂模式（三）
- 工厂三兄弟之抽象工厂模式（四）
- 工厂三兄弟之抽象工厂模式（五）
- 单例模式-Singleton Pattern
- 确保对象的唯一性——单例模式 （一）
- 确保对象的唯一性——单例模式 （二）
- 确保对象的唯一性——单例模式 （三）
- 确保对象的唯一性——单例模式 （四）
- 确保对象的唯一性——单例模式 （五）
- 原型模式-Prototype Pattern
- 对象的克隆——原型模式（一）
- 对象的克隆——原型模式（二）
- 对象的克隆——原型模式（三）
- 对象的克隆——原型模式（四）
- 建造者模式-Builder Pattern
- 复杂对象的组装与创建——建造者模式（一）
- 复杂对象的组装与创建——建造者模式（二）
- 复杂对象的组装与创建——建造者模式（三）
- 七个结构型模式
- 适配器模式-Adapter Pattern
- 不兼容结构的协调——适配器模式（一）
- 不兼容结构的协调——适配器模式（二）
- 不兼容结构的协调——适配器模式（三）
- 不兼容结构的协调——适配器模式（四）
- 桥接模式-Bridge Pattern
- 处理多维度变化——桥接模式（一）
- 处理多维度变化——桥接模式（二）
- 处理多维度变化——桥接模式（三）
- 处理多维度变化——桥接模式（四）
- 组合模式-Composite Pattern
- 树形结构的处理——组合模式（一）
- 树形结构的处理——组合模式（二）
- 树形结构的处理——组合模式（三）
- 树形结构的处理——组合模式（四）
- 树形结构的处理——组合模式（五）
- 装饰模式-Decorator Pattern
- 扩展系统功能——装饰模式（一）
- 扩展系统功能——装饰模式（二）
- 扩展系统功能——装饰模式（三）
- 扩展系统功能——装饰模式（四）
- 外观模式-Facade Pattern
- 深入浅出外观模式（一）
- 深入浅出外观模式（二）
- 深入浅出外观模式（三）
- 享元模式-Flyweight Pattern
- 实现对象的复用——享元模式（一）
- 实现对象的复用——享元模式（二）
- 实现对象的复用——享元模式（三）
- 实现对象的复用——享元模式（四）
- 实现对象的复用——享元模式（五）
- 代理模式-Proxy Pattern
- 设计模式之代理模式（一）
- 设计模式之代理模式（二）
- 设计模式之代理模式（三）
- 设计模式之代理模式（四）
- 十一个行为型模式
- 职责链模式-Chain of Responsibility Pattern
- 请求的链式处理——职责链模式（一）
- 请求的链式处理——职责链模式（二）
- 请求的链式处理——职责链模式（三）
- 请求的链式处理——职责链模式（四）
- 命令模式-Command Pattern
- 请求发送者与接收者解耦——命令模式（一）
- 请求发送者与接收者解耦——命令模式（二）
- 请求发送者与接收者解耦——命令模式（三）
- 请求发送者与接收者解耦——命令模式（四）
- 请求发送者与接收者解耦——命令模式（五）
- 请求发送者与接收者解耦——命令模式（六）
- 解释器模式-Interpreter Pattern
- 自定义语言的实现——解释器模式（一）
- 自定义语言的实现——解释器模式（二）
- 自定义语言的实现——解释器模式（三）
- 自定义语言的实现——解释器模式（四）
- 自定义语言的实现——解释器模式（五）
- 自定义语言的实现——解释器模式（六）
- 迭代器模式-Iterator Pattern
- 遍历聚合对象中的元素——迭代器模式（一）
- 遍历聚合对象中的元素——迭代器模式（二）
- 遍历聚合对象中的元素——迭代器模式（三）
- 遍历聚合对象中的元素——迭代器模式（四）
- 遍历聚合对象中的元素——迭代器模式（五）
- 遍历聚合对象中的元素——迭代器模式（六）
- 中介者模式-Mediator Pattern
- 协调多个对象之间的交互——中介者模式（一）
- 协调多个对象之间的交互——中介者模式（二）
- 协调多个对象之间的交互——中介者模式（三）
- 协调多个对象之间的交互——中介者模式（四）
- 协调多个对象之间的交互——中介者模式（五）
- 备忘录模式-Memento Pattern
- 撤销功能的实现——备忘录模式（一）
- 撤销功能的实现——备忘录模式（二）
- 撤销功能的实现——备忘录模式（三）
- 撤销功能的实现——备忘录模式（四）
- 撤销功能的实现——备忘录模式（五）
- 观察者模式-Observer Pattern
- 对象间的联动——观察者模式（一）
- 对象间的联动——观察者模式（二）
- 对象间的联动——观察者模式（三）
- 对象间的联动——观察者模式（四）
- 对象间的联动——观察者模式（五）
- 对象间的联动——观察者模式（六）
- 状态模式-State Pattern
- 处理对象的多种状态及其相互转换——状态模式（一）
- 处理对象的多种状态及其相互转换——状态模式（二）
- 处理对象的多种状态及其相互转换——状态模式（三）
- 处理对象的多种状态及其相互转换——状态模式（四）
- 处理对象的多种状态及其相互转换——状态模式（五）
- 处理对象的多种状态及其相互转换——状态模式（六）
- 策略模式-Strategy Pattern
- 算法的封装与切换——策略模式（一）
- 算法的封装与切换——策略模式（二）
- 算法的封装与切换——策略模式（三）
- 算法的封装与切换——策略模式（四）
- 模板方法模式-Template Method Pattern
- 模板方法模式深度解析（一）
- 模板方法模式深度解析（二）
- 模板方法模式深度解析（三）
- 访问者模式-Visitor Pattern
- 操作复杂对象结构——访问者模式（一）
- 操作复杂对象结构——访问者模式（二）
- 操作复杂对象结构——访问者模式（三）
- 操作复杂对象结构——访问者模式（四）
- 设计模式趣味学习（复习）
- 设计模式与足球（一）
- 设计模式与足球（二）
- 设计模式与足球（三）
- 设计模式与足球（四）
- 设计模式综合应用实例
- 多人联机射击游戏
- 多人联机射击游戏中的设计模式应用（一）
- 多人联机射击游戏中的设计模式应用（二）
- 数据库同步系统
- 设计模式综合实例分析之数据库同步系统（一）
- 设计模式综合实例分析之数据库同步系统（二）
- 设计模式综合实例分析之数据库同步系统（三）