状态模式,又称状态对象模式(Pattern of Objects for States),状态模式是对象的行为模式。
状态模式同意一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样。
定义与结构
GOF《设计模式》中给状态模式下的定义为:同意一个对象在其内部状态改变时改变它的行为。
这个对象看起来似乎改动了它的类。
看起来。状态模式好像是神通广大——竟然可以“改动自身的类”!
可以让程序依据不同的外部情况来做出不同的响应。最直接的方法就是在程序中将这些可能发生的外部情况所有考虑到,使用if else 语句来进行代码响应选择。
可是这样的方法对于复杂一点的状态推断,就会显得杂乱无章,easy产生错误;并且添加一个新的状态将会带来大量的改动。
这个时候“可以改动自身”的状态模式的引入或许是个不错的主意。
状态模式的结构
用一句话来表述,状态模式把所研究的对象的行为包装在不同的状态对象里,每个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候。其行为也随之改变。状态模式的示意性类图例如以下所看到的:
类图例如以下。结构很easy也与策略模式很相似。
|
状态模式所涉及到的角色有:
● 环境(Context)角色。也成上下文:定义client所感兴趣的接口,而且保留一个详细状态类的实例。这个详细状态类的实例给出此环境对象的现有状态。
● 抽象状态(State)角色:定义一个接口,用以封装环境(Context)对象的一个特定的状态所相应的行为。
● 详细状态(ConcreteState)角色:每个详细状态类都实现了环境(Context)的一个状态所相应的行为。
源码
环境角色类
抽象状态类
详细状态类
client类
从上面能够看出。环境类Context的行为request()是委派给某一个详细状态类的。通过使用多态性原则,能够动态改变环境类Context的属性State的内容,使其从指向一个详细状态类变换到指向还有一个详细状态类,从而使环境类的行为request()由不同的详细状态类来运行。
使用场景
考虑一个在线投票系统的应用,要实现控制同一个用户仅仅能投一票,假设一个用户重复投票,并且投票次数超过5次。则判定为恶意刷票。要取消该用户投票的资格,当然同一时候也要取消他所投的票;假设一个用户的投票次数超过8次,将进入黑名单,禁止再登录和使用系统。
要使用状态模式实现,首先须要把投票过程的各种状态定义出来。依据以上描写叙述大致分为四种状态:正常投票、重复投票、恶意刷票、进入黑名单。然后创建一个投票管理对象(相当于Context)。
系统的结构图例如以下所看到的:
源码
抽象状态类
详细状态类——正常投票
详细状态类——反复投票
详细状态类——恶意刷票
详细状态类——黑名单
环境类
client类
执行结果例如以下:
从上面的演示样例能够看出,状态的转换基本上都是内部行为,主要在状态模式内部来维护。比方对于投票的人员。不论什么时候他的操作都是投票,可是投票管理对象的处理却不一定一样,会依据投票的次数来推断状态,然后依据状态去选择不同的处理。
认识状态模式
● 状态和行为
所谓对象的状态,通常指的就是对象实例的属性的值;而行为指的就是对象的功能。再详细点说,行为大多能够相应到方法上。
状态模式的功能就是分离状态的行为,通过维护状态的变化,来调用不同状态相应的不同功能。也就是说,状态和行为是相关联的,它们的关系能够描写叙述为:状态决定行为。
因为状态是在执行期被改变的,因此行为也会在执行期依据状态的改变而改变。
● 行为的平行性
注意平行线而不是平等性。所谓平行性指的是各个状态的行为所处的层次是一样的,相互独立的、没有关联的,是依据不同的状态来决定究竟走平行线的哪一条。
行为是不同的,当然相应的实现也是不同的。相互之间是不可替换的。
而平等性强调的是可替换性,大家是同一行为的不同描写叙述或实现。因此在同一个行为发生的时候,能够依据条件挑选随意一个实现来进行对应的处理。
大家可能会发现状态模式的结构和策略模式的结构全然一样,可是,它们的目的、实现、本质却是全然不一样的。
还有行为之间的特性也是状态模式和策略模式一个非常重要的差别,状态模式的行为是平行性的,不可相互替换的;而策略模式的行为是平等性的。是能够相互替换的。
● 环境和状态处理对象
在状态模式中。环境(Context)是持有状态的对象,可是环境(Context)自身并不处理跟状态相关的行为。而是把处理状态的功能托付给了状态相应的状态处理类来处理。
在详细的状态处理类中常常须要获取环境(Context)自身的数据,甚至在必要的时候会回调环境(Context)的方法,因此。通常将环境(Context)自身当作一个參数传递给详细的状态处理类。
client一般仅仅和环境(Context)交互。
client能够用状态对象来配置一个环境(Context),一旦配置完成,就不再须要和状态对象打交道了。client通常不负责执行期间状态的维护,也不负责决定兴许究竟使用哪一个详细的状态处理对象。
状态VS策略
细致对照状态模式和策略模式。难免会产生疑问:这两个明明是一个东西嘛!
以下我们就来分析下两者差别。
首先我要声明,在实际应用中仅仅要可以使得你的代码灵活美丽起来。何必计较这些方方面面的区别呢?
Brandon Goldfedder在《模式的乐趣》里是怎么说的:“strategy模式在结构上与state模式很相似,可是在概念上,他们的目的差异很大。
区分这两个模式的关键是看行为是由状态驱动还是由一组算法驱动,这条规则似乎有点任意。可是在推断时还是须要考虑它。通常,State模式的“状态”是在对象内部的。Strategy模式的“策略”能够在对象外部。只是这也不是一条严格、可靠的规则。
”
我非常允许Brandon Goldfedder的观点。这两个模式的划分,就在于使用的目的是不同的——策略模式用来处理算法变化。而状态模式则是处理状态变化(好玄乎阿)。
策略模式中,算法是否变化全然是由客户程序开决定的。并且往往一次仅仅能选择一种算法。不存在算法中途发生变化的情况。从《深入浅出策略模式》中的样例能够非常好的看出。
而状态模式如定义中所言,在它的生命周期中存在着状态的转变和行为得更改,并且状态变化是一个线形的总体。对于客户程序来言,这样的状态变化往往是透明的。
本文借鉴博客:
http://www.cnblogs.com/java-my-life/archive/2012/06/08/2538146.html
http://dev.yesky.com/438/2164938.shtml
http://blog.csdn.net/column/details/loveyun.html?
&page=1http://www.cnblogs.com/BenWong/archive/2012/12/12/2813982.html