设计模式(行为型)之状态模式(State Pattern)

PS一句：最终还是选择CSDN来整理发表这几年的知识点，该文章平行迁移到CSDN。因为CSDN也支持MarkDown语法了，牛逼啊！

【工匠若水 http://blog.csdn.net/yanbober】 阅读前一篇《设计模式(行为型)之模板方法模式(Template Method Pattern)》http://blog.csdn.net/yanbober/article/details/45501715

概述

状态模式用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行为不相同时可以使用状态模式。状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化，对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致处理。

核心

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

状态模式结构重要核心模块：

Context（环境类）

环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同，因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象。

State（抽象状态类）

它用于定义一个接口以封装与环境类的一个特定状态相关的行为，在抽象状态类中声明了各种不同状态对应的方法，而在其子类中实现类这些方法，由于不同状态下对象的行为可能不同，因此在不同子类中方法的实现可能存在不同，相同的方法可以写在抽象状态类中。

ConcreteState（具体状态类）

它是抽象状态类的子类，每一个子类实现一个与环境类的一个状态相关的行为，每一个具体状态类对应环境的一个具体状态，不同的具体状态类其行为有所不同。

使用场景

对象的行为依赖于它的某些属性值，状态的改变将导致行为的变化。

在代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，并且导致客户类与类库之间的耦合增强。

程序猿实例

这里展示一个状态模式最基本的简单例子（模拟Android App网络请求资源的状态），严格遵守状态模式几大核心模板，不多解释：

package yanbober.github.io;

//State（抽象状态类）
interface State {
    void handleState(String str);
}
//ConcreteState（具体状态类）
class ConcreteStateWating implements State {
    @Override
    public void handleState(String str) {
        System.out.println("State: wating, str="+str);
    }
}

class ConcreteStateLoading implements State {
    @Override
    public void handleState(String str) {
        System.out.println("State: loading, str="+str);
    }
}

class ConcreteStateFinish implements State {
    @Override
    public void handleState(String str) {
        System.out.println("State: finish, str="+str);
    }
}

class ConcreteStateError implements State {
    @Override
    public void handleState(String str) {
        System.out.println("State: error, str="+str);
    }
}
//Context（环境类）
class Context {
    private State state;

    public void setState(State state) {
        this.state = state;
    }

    public void request(String str) {
        state.handleState(str);
    }
}
//客户端
public class Main {
    public static void main(String[] args) {
        Context context = new Context();
        context.setState(new ConcreteStateWating());
        context.request("1");
        context.setState(new ConcreteStateLoading());
        context.request("2");
        context.setState(new ConcreteStateFinish());
        context.request("3");
        context.setState(new ConcreteStateError());
        context.request("e");
    }
}

总结一把

状态模式优点：

封装了状态的转换规则，在状态模式中可以将状态的转换代码封装在环境类或者具体状态类中，可以对状态转换代码进行集中管理，而不是分散在一个个业务方法中。

将所有与某个状态有关的行为放到一个类中，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为。

允许状态转换逻辑与状态对象合成一体，而不是提供一个巨大的条件语句块，状态模式可以让我们避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起。

可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

状态模式缺点：

状态模式的使用必然会增加系统中类和对象的个数，导致系统运行开销增大。

状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱，增加系统设计的难度。

状态模式对“开闭原则”的支持并不太好，增加新的状态类需要修改那些负责状态转换的源代码，否则无法转换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。

【工匠若水 http://blog.csdn.net/yanbober】 继续阅读《设计模式(行为型)之职责链模式(Chain of Responsibility Pattern)》 http://blog.csdn.net/yanbober/article/details/45531395