CH15-行为型-状态

模式动机

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

模式定义

状态模式(State Pattern):允许一个对象在其内部状态改变时改变它自身的行为,对象开起来似乎修改了它的类。其别名为状态对象(Objects for states)。

模式结构

包含 3 种角色:

  • Context:环境类
  • State:抽象状态类
  • ConcreteState:具体状态类

类图

NAME

时序图

NAME

模式分析

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

需要理解环境类与抽象状态类的作用:

  • 环境类实际上就是拥有状态的对象,有时候可以充当状态管理器(State Manager)的角色,可以在环境类中对状态进行切换操作。

  • 抽象状态类可以是抽象类,也可以是接口,不同状态类就是继承这个父类的不同子类,状态类的产生是由于环境类存在多个状态,同时还满足两个条件:

    • 这些状态需要经常切换
    • 不同状态下,对象的行为不同

    因此,可以将不同对象下的行为单独提取出来封装在具体的状态类中,使得环境类对象在其内部状态改变时可以改变它的行为,对象看起来似乎修改了它的类,实际上是由于切换到不同的状态类实现的。

  • 由于环境类可以设置为任一具体状态类,因此它针对抽象状态类进行编程,在程序运行时可以将任一具体状态类的对象设置到环境类中,从而使得环境类可以改变内部状态,并且改变行为。

优点

  • 封装了转换规则
  • 枚举可能的状态,在枚举状态之前需要确定状态种类
  • 将所有与某个状态有关的行为放到一个类中,并且可以方便的增加新的状态,只需要改变对象状态即可改变对象行为。
  • 允许状态转换逻辑与状态对象合成一体,而不是一个巨大的条件语句块。
  • 可以让多个环境对象共现一个状态对象,从而减少系统中对象的个数。

缺点

  • 必然增加系统类和对象的个数
  • 结构与实现比较复杂,使用不当将导致结构与代码混乱
  • 对“开闭原则”的支持并不是很好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态装换的源代码,否则无法切换到新增状态;修改某个状态类的行为也需要修改对应类的源代码。

适用场景

  • 对象的行为依赖于其状态(属性),并且需要根据它的状态改变而改变相关行为。
  • 代码中包含大量与对象状态有关的条件语句,这些条件语句的出现,会导致代码的可维护性和灵活性变差,不能方便的增加和删除状态,使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为,而且这些条件对应于对象的各种状态。