公告

如果您是第一次阅读我的设计模式系列文章，建议先阅读设计模式开篇，希望能得到您宝贵的建议。

前言

随着上文装饰器模式提到店铺老板Bob改良了机器人的选型过程，价格又比你的店铺实惠销量得到了显著增长。因此，你决定要加大促销力度，再一番折扣刺激过后。烦人的Alice又出现了，这次又会提出怎样的需求呢？

正文

某天下午Alice跑到了你的门店，抱怨他购买的机器人 “播放歌曲的功能失灵了”。再也没法听到机器人曼妙的歌声。

作为一个“有良心”的卖家，当然不能把产品没做好的事情抖出去。于是你扛起正义的大旗，保证帮Alice把机器人修好。

程序员视角

现在我们希望实现这样一个功能 — — “播放音乐”。我们告诉机器人对应的指令，机器人就会默默的为我们查询歌曲并播放（唱出来）。

如何实现

罗列下业务事件：

搜索歌曲、下载歌曲、播放歌曲、暂停歌曲等这些功能都很好实现，但是其状态转化却是相对比较复杂的。

比如给机器人发口令“播放周杰伦的稻香”：
1、机器人会先搜索稻香、周杰伦关键字。
2、搜到成功后下载到本机。
3、然后在执行播放按钮。

但这只是众多情况中的一种成功情况，还有很多的异常分支需要把控。

状态模式：分离状态的行为，构建状态转移方程的同时不用陷入到实现细节中。

这个例子中状态分为几种：
1、外部驱动 — — 发送口令播放
2、内部驱动 — — 播放口令后的一系列查询，下载，播放行为

如果适用的场景全部是外部驱动，则策略模式与命令模式也可以适用。
如果适用的场景全部是内部驱动，则可构建有限状态机。

代码实现

状态的上层接口

public interface IMusicState {

    // 执行音乐相关操作
    IMusicState handle(ContextState contextState, Music music);

    // 状态是内部驱动还是外部驱动
    boolean isDependOnUserAction();

}

状态管理器（状态客户端）

public class ContextState {

    private IMusicState state;

    public IMusicState getState() {
        return state;
    }

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

    public synchronized void loop(Music music) {
        while (true) {

            if (this.state == null) {
                this.state = new PendingStateImpl();
            }
            this.state = this.state.handle(this, music);
            if (this.state.isDependOnUserAction()) {
                System.out.println("等待用户再次触发状态的改变.");
                break;
            }
        }
    }
}

状态类

播放状态 —— 此处仅举出一例，其余状态结构相似

public class PlayStateImpl extends MusicState {
    public PlayStateImpl() {
        System.out.println("构建 PlayStateImpl");
    }

    @Override
    public IMusicState handle(ContextState contextState, Music music) {
        if (music.url == null) {
            return new SearchStateImpl();
        }
        if (!music.isDownload) {
            return new DownloadStateImpl();
        }
        return new PauseStateImpl();
    }

    @Override
    public boolean isDependOnUserAction() {
        return false;
    }
}

执行结果

构建 PendingStateImpl
构建 PlayStateImpl
构建 PauseStateImpl
等待用户再次触发状态的改变.

总结

在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的(stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。
在UML中可以使用状态图来描述对象状态的变化。

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

状态模式类图

状态模式描述了对象状态的变化以及对象如何在每一种状态下表现出不同的行为。
状态模式的关键是引入了一个抽象类来专门表示对象的状态，这个类我们叫做抽象状态类，而对象的每一种具体状态类都继承了该类，并在不同具体状态类中实现了不同状态的行为，包括各种状态之间的转换。

在状态模式结构中需要理解环境类与抽象状态类的作用：

环境类实际上就是拥有状态的对象，环境类有时候可以充当状态管理器(State Manager)的角色，可以在环境类中对状态进行切换操作。
抽象状态类可以是抽象类，也可以是接口，不同状态类就是继承这个父类的不同子类，状态类的产生是由于环境类存在多个状态，同时还满足两个条件：

这些状态经常需要切换，在不同的状态下对象的行为不同。因此可以将不同对象下的行为单独提取出来封装在具体的状态类中，使得环境类对象在其内部状态改变时可以改变它的行为，对象看起来似乎修改了它的类，而实际上是由于切换到不同的具体状态类实现的。由于环境类可以设置为任一具体状态类，因此它针对抽象状态类进行编程，在程序运行时可以将任一具体状态类的对象设置到环境类中，从而使得环境类可以改变内部状态，并且改变行为。

状态模式（分离状态，选择实现）