如何让孩子爱上设计模式 ——23.状态模式(State Pattern)
标签： 设计模式初涉
描述性文字
分离状态，选择实现
定义
当一个对象的内在状态发生改变时允许改变其行为，这个对象看起来像是改变了它的类
三个角色
- Context：上下文环境，定义客户感兴趣的接口，维护一个State子类的实例，该实例定义了对象的当前状态
- State：抽象状态，定义一个接口以封装与 Context 的一个特定状态相关的行为。
- ConcreteState：具体状态，实现抽象状态中定义的接口，从而达到不同状态下的不同行为。
UML类图
使用场景
- 1.对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为；
- 2.代码中包含大量与对象状态有关的条件语句
优缺点
优点
- 1.简化应用逻辑控制，减少依赖于状态的if-else
- 2.更好的分离状态和行为
- 3.更好的扩展性，扩展新的状态只需增加实现类，在需要维护的地方设置新状态即可
- 4.显式化进行状态转换
缺点
- 1.类文件增加
- 2.逻辑分散，无法再一个地方就看出整个状态机的逻辑
示例代码
状态模式非常简单，就是抽象出状态State，然后实现该接口，然后具体化不同状态，
做不同的操作，然后写一个Context，里面存储一个State的实例，然后定义一个
可以修改State实例的方法，并在里面去调用实例的行为方法。写个不同时刻做
不同事情的例子帮助理解下~
先定义抽象状态
三个具体状态，早上睡懒觉，下午学习，晚上打球
然后是Context类，就写一个设置State的方法
最后客户端调用下
输出结果
好的，状态模式还是非常简单的，可能细心的你发现了状态模式和策略模式非常的类似，
其实还是有些不同的，比如Context类，策略模式只是一个委托作用，负责算法替换；而状态模式
不仅仅是委托作用，还具有等级状态变化的功能，与具体的状态类协作，共同完成状态切换的任务。
策略模式封装的是不同算法，算法间没有交互，已达到算法可以*切换的目的；
状态模式封装的是不同状态，以达到状态切换行为随之发生改变的目的。
本节代码示例
https://github.com/coder-pig/DesignPatternsExample/tree/master/22.State%20Pattern