状态模式
在状态模式(State Pattern)中,类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。
在状态模式中,我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。
介绍
意图:允许对象在内部状态发生改变时改变它的行为,对象看起来好像修改了它的类。
主要解决:对象的行为依赖于它的状态(属性),并且可以根据它的状态改变而改变它的相关行为。
何时使用:代码中包含大量与对象状态有关的条件语句。
如何解决:将各种具体的状态类抽象出来。
关键代码:通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且,状态模式的实现类的方法,一般返回值,或者是改变实例变量的值。也就是说,状态模式一般和对象的状态有关。实现类的方法有不同的功能,覆盖接口中的方法。状态模式和命令模式一样,也可以用于消除 if...else 等条件选择语句。
应用实例: 1、打篮球的时候运动员可以有正常状态、不正常状态和超常状态。 2、曾侯乙编钟中,'钟是抽象接口','钟A'等是具体状态,'曾侯乙编钟'是具体环境(Context)。
优点: 1、封装了转换规则。 2、枚举可能的状态,在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中,并且可以方便地增加新的状态,只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体,而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象,从而减少系统中对象的个数。
缺点: 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源代码,否则无法切换到新增状态,而且修改某个状态类的行为也需修改对应类的源代码。
使用场景: 1、行为随状态改变而改变的场景。 2、条件、分支语句的代替者。
注意事项:在行为受状态约束的时候使用状态模式,而且状态不超过 5 个。
实现
我们将创建一个 State 接口和实现了 State 接口的实体状态类。Context 是一个带有某个状态的类。
StatePatternDemo,我们的演示类使用 Context 和状态对象来演示 Context 在状态改变时的行为变化。
步骤 1
创建一个接口。
State.java
步骤 2
创建实现接口的实体类。
StartState.java
StopState.java
步骤 3
创建 Context 类。
Context.java
步骤 4
使用 Context 来查看当状态 State 改变时的行为变化。
StatePatternDemo.java
步骤 5
执行程序,输出结果:
Player is in start state Start State Player is in stop state Stop State
匿名者
243***0082@qq.com
状态模式有些问题,应当如下设计:
State接口如下:
StartState 类设计如下:
CloseState 类:
Context 类:
StatePatternDemo 设计如下:
匿名者
243***0082@qq.com
醉梦先森
197***8624@qq.com
上述笔记代码有点问题,开机状态和关机状态需要修改成下面这样:
Context类也要修改:
醉梦先森
197***8624@qq.com
Johnny
yhr***@163.com
上述代码可以优化一下,增加了判断,已经 start 的需要设置状态为 start。
Context.java 如下:
Johnny
yhr***@163.com
Siskin.xu
sis***@sohu.com
Python 方式:
Siskin.xu
sis***@sohu.com
YesOk
862***656@qq.com
第一个笔记这样改写,用的是策略模式。不是状态模式,对象的行为依赖于它的状态(属性),随状态改变而改变它的相关行为,看 demo 例子:
Start或Stop的状态改变,context打印出的状态,是随状态改变而变的。实际应用场景,只需要判断context的状态,业务逻辑做相应变化。
第二个笔记,每个状态都独立的,反而将状态之间耦合在一起,改成例子那样,多好:
以上个人观点,欢迎交流学习。
YesOk
862***656@qq.com
养吾剑
979***716@qq.com
这个完全误人子弟了。
笔记二是对的,最后一个笔记yesok的再次误人子弟。
把context换成computer就明白了,computer如果只有开机,关机,播放三种操作,但是有开机,关机,播放中三种状态。每种状态能够执行的操作肯定是不同的。
开机 关机 播放
开机中 不可 可 可
关机中 可 不可 不可
播放中 不可 可 不可
状态即使抽象出来,也只是computer的属性,方便扩展不写switch而已,状态的变化肯定是源于computer自身的动作的,用oo的思想来看,调用者对于状态state的api应该是不可见的。
new computer时,会设置一个默认状态,我们的例子应该是关机中。然后关机中的computer只能有一个有效操作,就是开机,至于其他两种操作是设置为无响应,还是log提示无法操作,那也随便了。
最后,状态切换本身就是每个状态的内禀属性,关机中通过开机操作切换到开机中的代码,应该写在CloseState里,至于说耦合问题,这些状态本身互相之间就是有联系的,怎么可能互相独立?
养吾剑
979***716@qq.com