设计模式(8)：行为型-状态模式(State)

设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络，如同大厦的结构一样。

设计模式分为三种类型，共23种。
创建型模式(5)：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
结构型模式(7)：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
行为型模式(11)：(父子类)策略模式、模版方法模式，(两个类)观察者模式、迭代器模式、职责链模式、命令模式，(类的状态)状态模式、备忘录模式，(中间类) 访问者模式、中介者模式、解释器模式。

　　“人有悲欢离合，月有阴晴圆缺”，包括人在内，很多事物都具有多种状态，而且在不同状态下会具有不同的行为，这些状态在特定条件下还将发生相互转换。就像水，它可以凝固成冰，也可以受热蒸发后变成水蒸汽，水可以流动，冰可以雕刻，蒸汽可以扩散。
　　在软件系统中，有些对象也像水一样具有多种状态，这些状态在某些情况下能够相互转换，而且对象在不同的状态下也将具有不同的行为。为了更好地对这些具有多种状态的对象进行设计，我们可以使用一种被称之为状态模式的设计模式，本章我们将学习用于描述对象状态及其转换的状态模式。

一.概述

银行系统中的账户类设计

　　Sunny软件公司欲为某银行开发一套信用卡业务系统，银行账户(Account)是该系统的核心类之一，通过分析，Sunny软件公司开发人员发现在该系统中，账户存在三种状态，且在不同状态下账户存在不同的行为，具体说明如下：
(1) 如果账户中余额大于等于0，则账户的状态为正常状态(Normal State)，此时用户既可以向该账户存款也可以从该账户取款；
(2) 如果账户中余额小于0，并且大于-2000，则账户的状态为透支状态(Overdraft State)，此时用户既可以向该账户存款也可以从该账户取款，但需要按天计算利息；
(3) 如果账户中余额等于-2000，那么账户的状态为受限状态(Restricted State)，此时用户只能向该账户存款，不能再从中取款，同时也将按天计算利息；
(4) 根据余额的不同，以上三种状态可发生相互转换。
部分代码如下:

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，在该状态下既不允许存款也不允许取款），需要对原有代码进行大量修改，扩展起来非常麻烦。
为了解决这些问题，我们可以使用状态模式，在状态模式中，我们将对象在每一个状态下的行为和状态转移语句封装在一个个状态类中，通过这些状态类来分散冗长的条件转移语句，让系统具有更好的灵活性和可扩展性，状态模式可以在一定程度上解决上述问题。

定义

　　状态模式(State Pattern)：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。
　　State Pattern:Allow an object to alter its behavior when its internal state changes.The object will appear to change its class.

结构

　　在状态模式中引入了抽象状态类和具体状态类，它们是状态模式的核心，其结构如图3所示：

在状态模式结构图中包含如下几个角色：

• Context（环境类）：环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同，因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象。
• State（抽象状态类）：它用于定义一个接口以封装与环境类的一个特定状态相关的行为，在抽象状态类中声明了各种不同状态对应的方法，而在其子类中实现类这些方法，由于不同状态下对象的行为可能不同，因此在不同子类中方法的实现可能存在不同，相同的方法可以写在抽象状态类中。
• ConcreteState（具体状态类）：它是抽象状态类的子类，每一个子类实现一个与环境类的一个状态相关的行为，每一个具体状态类对应环境的一个具体状态，不同的具体状态类其行为有所不同。

实现

典型代码如下所示：