如何让孩子爱上设计模式 ——23.状态模式(State Pattern)

如何让孩子爱上设计模式 ——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