状态模式

概念

状态模式允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类.

这个描述中的第一部分的含义:这个模式将状态封装成为独立的类,并将动作委托到代表当前状态的对象,我们知道行为会随着内部状态而改变,当对象处于不同状态时,就会得到不同的行为.

第二部分的含义:如果说你使用的对象能够完全改变它的行为,那么你会觉得,这个对象实际上是从别的类实例化而来的.然而实际上是在使用组合通过简单引用不同状态对象来造成类改变的假象.

适用场景

1. 一个对象的行为取决于它的状态, 并且在运行时刻根据状态改变它的行为
2. 代码中包含大量与对象状态有关的条件语句:一个操作中有庞大的多分支的条件语句, 而这些分析依赖于该对象的状态. 这个状态通常用多个枚举常量表示. 通常, 有多个操作包含这一相同的条件结构. 状态模式将每一个条件分支放入一个独立的类中. 这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化.

结构

环境类(Context) 定义客户感兴趣的接口, 维护一个State类的引用/指针, 指向一个当前状态的ConcreteState实例

抽象状态类(State) 定义一个接口以封装与Context的一个特定状态相关的行为

具体状态类(ConcreteState) 每一子类实现一个Context的一种状态的行为

优缺点

优点

1. 它将与状态相关的行为局部化, 并且将不同状态的行为分割开来: 这样做的好处是,所有与状态相关的代码都存在于某一个State子类中, 使得增加新的状态很容易, 新增状态不会影响其他状态的代码;避免巨大的if-else或switch-case语句块, 使得程序代码结构化, 并使其意图更加清晰

2. 它使得状态转换显式化: 当一个对象仅以内部状态值来定义当前状态时, 其状态改变仅表现为对一些变量的赋值, 这不够明确.为不同状态引入独立的对象, 使得转变变得更加明确. 而且state对象可保证Context不会发生内部状态不一致的情况, 因为从context的角度来看,状态转换时原子的, 只要重新绑定一个变量(即context的state对象), 而无需为多个变量赋值

3. state对象可被共享. 如果state对象没有实例变量--即它们表示的状态完全以它们的类型来编码--那么各context对象可以共享一个state对象, 当状态以这种方式共享时, 它们必然是没有内部状态, 只有行为的轻量级对象

缺点

1. 状态模式的使用必然会增加系统的类和对象的个数

2. 状态模式的结构与实现都较为复杂, 如果使用不当将导致程序结构和代码的混乱

与策略模式的区别

1. 状态模式与策略模式都是使用组合和委托,但意图是完全不一样的: 策略模式通常有一个实例化的类,而且通常给它一个实现某些行为的策略对象, 使得这个实例化的类能够具备某种能力.而状态模式利用许多不同的状态对象,在Context创建之后,告诉它们从什么状态开始, 并且使它的Context对象随着时间而改变状态, 而任何的状态改变都是定义好的

2. 策略模式通常会用行为或算法来配置Context类, 状态模式允许Context随着状态的改变而改变行为

实现

待补充