定义

很多时候,一个对象的行为会根据一个动态的属性变化而变化,这样的一个对象我们可以称为是有状态的对象。

那么状态模式就是允许一个对象在其内部状态改变时候去改变对象的行为. 状态模式的关键就是区分其对象内部动态变化状态是什么。

现实世界举例论证

一个电灯泡,有一个开关按钮, 默认是关闭状态,按一下切换到亮灯状态,再按一下切换到关闭状态，循环往复。

我们使用面向对象写法实现上述的场景。

class Button {
    constructor (light) {        this.light = light;    }
    onPress () {        if (this.light.status === 'close') {            this.light.status = 'open';
            console.log('开灯');        } else {            this.light.status = 'close';
            console.log('关灯');        }    }
}class Light {
    constructor () {
        this.status = 'close';    }}

const light = new Light();const button = new Button(light);button.onPress();button.onPress();button.onPress();
 
但是现实场景中有些灯的状态不只是开关，比如它还是只有一个开关，第一次按是开弱光，再按是开强光，再按才是关，依次循环。
此时我们的代码如何按照下述方法扩展:
class Button {
    constructor (light) {        this.light = light;    }
    onPress () {        if (this.light.status === 'close') {            this.light.status = 'light';
            console.log('开弱光灯');        } else if (this.light.status === 'light') {            this.light.status = 'strong';
            console.log('开强光灯');        } else {            this.light.status = 'close';
            console.log('关灯');        }    }
}
 
你会发下上述代码的缺点:
违反SOLID中的O原则(对扩展开发，对修改关闭)。
每次增加一个灯的状态，就要修该onPress方法,使得代码非常不稳定,不利于维护。
过多的if else, 不利于代码阅读。
我们可以使用状态模式对上述代码进行重构。
找出状态对象中的可变属性,将其抽象为一个单独的类，跟这个状态有关的行为都封装在其类里面。
class Button {
    constructor (light) {        this.weakLightStatus = new WeakLightStatus(light);
        this.strongLightStatus = new StrongLightStatus(light);        this.offLightStatus = new OffLightStatus(light);    }    onPress () {
        this[light.status].onPress();    }}

class Light {
    constructor () {        this.status = 'offLightStatus';
    }
    // 切换状态类
    setStatus (statusClass) {
        this.status = statusClass;
    }
}// 抽象类
class LightStatus {
    constructor (light) {        this.light = light;
    }
}// 弱光
class WeakLightStatus extends LightStatus {    constructor (light) {        super(light);    }    onPress () {        this.light.setStatus('strongLightStatus');        console.log('开弱光灯');    }
}

// 强光class StrongLightStatus extends LightStatus {    constructor (light) {        super(light);    }    onPress () {
        this.light.setStatus('offLightStatus');
        console.log('开强光灯');    }}// 关闭
class OffLightStatus extends LightStatus {    constructor (light) {        super(light);    }    onPress () {        this.light.setStatus('weakLightStatus');        console.log('关灯');
    }
}

const light = new Light();

const button = new Button(light);

button.onPress();
button.onPress();
button.onPress();
button.onPress();
 
通过重构之后的代码, 很明显就是提供了代码的可阅读性, 可维护性.方便后续需求的扩展，虽然会增加一定的代码量.
现在我们通过对GOF书中对状态模式的定义来加深自己的总结:
允许一个对象在其内部状态变化时候去改变它的行为, 对象似乎看起来改变了它的类
 
归纳分析:
把变化的属性(状态)封装成不同的类, 并把请求委托给当前的对象状态, 不同的状态此时执行不同的行为
从使用者角度看, 我们使用的对象在不同状态下有不同的行为, 彷佛这个对象是由不同类实例化而来, 这是因为请求委托的缘故
模式结构
状态模式包含如下角色：
Context: 环境类
State: 抽象状态类
ConcreteState: 具体状态类
类比之前我们上述的实例场景: Context指的就是Button类. State指的就是LightStatus. ConcreteState指的就是各个不同状态的类。
状态模式描述了对象状态的变化以及对象如何在每一种状态下表现出不同的行为。
状态模式的关键是引入了一个抽象类来专门表示对象的状态，这个类我们叫做抽象状态类，而对象的每一种具体状态类都继承了该类，并在不同具体状态类中实现了不同状态的行为，包括各种状态之间的转换。
在状态模式结构中需要理解环境类与抽象状态类的作用：
环境类实际上就是拥有状态的对象，环境类有时候可以充当状态管理器(State Manager)的角色，可以在环境类中对状态进行切换操作。
抽象状态类可以是抽象类，也可以是接口，不同状态类就是继承这个父类的不同子类，状态类的产生是由于环境类存在多个状态，同时还满足两个条件： 这些状态经常需要切换，在不同的状态下对象的行为不同。因此可以将不同对象下的行为单独提取出来封装在具体的状态类中，使得环境类对象在其内部状态改变时可以改变它的行为，对象看起来似乎修改了它的类，而实际上是由于切换到不同的具体状态类实现的。由于环境类可以设置为任一具体状态类，因此它针对抽象状态类进行编程，在程序运行时可以将任一具体状态类的对象设置到环境类中，从而使得环境类可以改变内部状态，并且改变行为。
状态模式的优缺点
优点:
状态模式定义的状态-行为的对应关系, 并将其封装在一个类里面, 我们只需要扩展具体状态类就可以扩展需求
避免了Context类的代码无限膨胀和过多的条件分支判断
Context类中的请求于具体状态类的行为隔离互补影响
缺点：
如果状态类很多, 需要不断扩展代码量
状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱
状态模式对“开闭原则”的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码
状态模式的性能优化点
管理State对像的创建与销毁: 有两种方式实现. 1. 仅仅当Satte对象需要的时候才去创建(节省内存).这个适合与那些State对象比较庞大的情景. 2. 一开始就创建所有的State对象,适用于State对象不多,以及状态频繁切换使用的情景.
我们上面的例子是一开始就创建了所有的State对象, 而且是为每一个Context类实例都创建了一组State对象,实际上我们这些State对象是可以在不同的Context类之间进行共享的(享元模式,后续再扩展说这一块).
适用环境
对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为。
代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为，而且这些条件对应于对象的各种状态。
参考资料：https://design-patterns.readthedocs.io/zh_CN/latest/behavioral_patterns/state.html#