状态模式和策略模式是孪生兄弟。他们都是为了解决产生多重if,else这种判断下形成的设计模式。为了让系统充满弹性和可维护性。策略模式是围绕互换的算法来创建业务,解决这个问题。而状态模式跟策略模式更不一样了,他是通过改变对象内部的状态来帮助对象控制自己的行为。
概念
定义
状态模式允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。本质:“根据状态分离和选择行为”
结构
状态模式有三个角色。“状态接口”和”状态实体类”和”上下文环境”。
Context(上下文环境)一般是用来定义客户感兴趣的接口,同时维护一个来具体处理当前状态的实例对象。
state(状态接口)用来封装与上下文交互的状态行为,约束状态实体类应该如何处理的方法
ConcreteState(状态实体类)具体实现状态处理的类,每个类实现一个跟上下文相关的状态的具体处理。
关键说明
状态模式我认为是活用了里氏代换和单一职责的一个模式。在使用者看来,他是换了一个对象来实现更改了内部的状态调用,其实是巧用了里氏代换,面向接口编程的思想。使用者只需简单的向上转型即可。其关键处我觉得是在Context上,该类必须把持State接口,且需要有一个允许外界注入State的入口,还需要一个给予用户调用的方法,该方法转接不同状态下的处理。
小实例
State类,状态接口。约束不同状态的实现继承,同时供上下文调用。
/**
* 封装与Context的一个特定状态相关的行为
*/
public interface State {
/**
* 状态对应的处理
* @param sampleParameter 示例参数,说明可以传入参数,具体传入
* 什么样的参数,传入几个参数,由具体应用来具体分析
*/
public void handle(String sampleParameter);
}
ConcreteState。实体状态类,每个类表示一种状态,实现State接口,受它约束。根据State接口的要求,实现在该状态下对应的处理方式
/**
* 实现一个与Context的一个特定状态相关的行为
*/
public class ConcreteStateA implements State {
public void handle(String sampleParameter) {
//实现具体的处理
}
}
/**
* 实现一个与Context的一个特定状态相关的行为
*/
public class ConcreteStateB implements State {
public void handle(String sampleParameter) {
//实现具体的处理
}
}
Context类,上下文环境类。我觉得最重要是因为它是与外界交互的一个大门。定义了客户需要使用的接口,转接给不同状态下的处理。同时它维护一个处理当前状态的实例对象
/**
* 定义客户感兴趣的接口,通常会维护一个State类型的对象实例
*/
public class Context {
/**
* 持有一个State类型的对象实例
*/
private State state;
/**
* 设置实现State的对象的实例
* @param state 实现State的对象的实例
*/
public void setState(State state) {
this.state = state;
}
/**
* 用户感兴趣的接口方法
* @param sampleParameter 示意参数
*/
public void request(String sampleParameter) {
//在处理中,会转调state来处理
state.handle(sampleParameter);
}
}
具体实例
投票系统。每个用户只能投一票。如果一个用户反复投票次数超过五次,则判定为恶意刷票,要取消该用户投票的资格,当然同时也要取消他所投的票。如果一个用户的投票次数超过8次,将进入黑名单,禁止再登录和使用系统。
这里有四种状态
一是用户是正常投票
二是用户正常投票过后,有意或者无意的重复投票
三是用户恶意投票
四是黑名单用户
我们先用传统的不使用模式的解决方案和用模式的解决方案来做一个对比。
不用状态模式的解决方案
/**
* 投票管理
*/
public class VoteManager {
/**
* 记录用户投票的结果,Map<String,String>对应Map<用户名称,投票的选项>
*/
private Map<String,String> mapVote =
new HashMap<String,String>();
/**
* 记录用户投票次数,Map<String,Integer>对应Map<用户名称,投票的次数>
*/
private Map<String,Integer> mapVoteCount =
new HashMap<String,Integer>();
/**
* 投票
* @param user 投票人,为了简单,就是用户名称
* @param voteItem 投票的选项
*/
public void vote(String user,String voteItem){
//1:先为该用户增加投票的次数
//先从记录中取出已有的投票次数
Integer oldVoteCount = mapVoteCount.get(user);
if(oldVoteCount==null){
oldVoteCount = 0;
}
oldVoteCount = oldVoteCount + 1;
mapVoteCount.put(user, oldVoteCount);
//2:判断该用户投票的类型,到底是正常投票、重复投票、恶意投票
//还是上黑名单,然后根据投票类型来进行相应的操作
if(oldVoteCount==1){
//正常投票
//记录到投票记录中
mapVote.put(user, voteItem);
System.out.println("恭喜你投票成功");
}else if(oldVoteCount>1 && oldVoteCount<5){
//重复投票
//暂时不做处理
System.out.println("请不要重复投票");
}else if(oldVoteCount >= 5 && oldVoteCount<8){
//恶意投票
//取消用户的投票资格,并取消投票记录
String s = mapVote.get(user);
if(s!=null){
mapVote.remove(user);
}
System.out.println("你有恶意刷票行为,取消投票资格");
}else if(oldVoteCount>=8){
//黑名单
//记入黑名单中,禁止登录系统了
System.out.println("进入黑名单,将禁止登录和使用本系统");
}
}
}
看到上面的大量if和else没有。每个都代表一种状态,即使只为演示,省略了不同状态下的处理行为,仍然是长篇。而状态模式就是封装不同状态下内部的一个处理行为。接下来使用设计模式
使用状态模式的解决方案
state状态接口
/**
* 封装一个投票状态相关的行为
*/
public interface VoteState {
/**
* 处理状态对应的行为
* @param user 投票人
* @param voteItem 投票项
* @param voteManager 投票上下文,用来在实现状态对应的功能处理的时候,
* 可以回调上下文的数据
*/
public void vote(String user,String voteItem
,VoteManager voteManager);
}
实现状态接口。每个类代表了投票下的不同状态即其相应的处理。
先看正常投票状态对应的处理,示例代码如下:
public class NormalVoteState implements VoteState{
public void vote(String user, String voteItem
,VoteManager voteManager) {
//正常投票
//记录到投票记录中
voteManager.getMapVote().put(user, voteItem);
System.out.println("恭喜你投票成功");
}
}
接下来看看重复投票状态对应的处理,示例代码如下:
public class RepeatVoteState implements VoteState{
public void vote(String user, String voteItem
,VoteManager voteManager) {
//重复投票
//暂时不做处理
System.out.println("请不要重复投票");
}
}
接下来看看恶意投票状态对应的处理,示例代码如下:
public class SpiteVoteState implements VoteState{
public void vote(String user, String voteItem
,VoteManager voteManager) {
//恶意投票
//取消用户的投票资格,并取消投票记录
String s = voteManager.getMapVote().get(user);
if(s!=null){
voteManager.getMapVote().remove(user);
}
System.out.println("你有恶意刷票行为,取消投票资格");
}
}
接下来看看黑名单状态对应的处理,示例代码如下:
public class BlackVoteState implements VoteState{
public void vote(String user, String voteItem
,VoteManager voteManager) {
//黑名单
//记入黑名单中,禁止登录系统了
System.out.println("进入黑名单,将禁止登录和使用本系统");
}
}
最后是重要的投票管理,相当于状态模式中的上下文。投票管理的投票方法,根据不同的投票行为转给不同的状态处理方法
/**
* 投票管理
*/
public class VoteManager {
/**
* 持有状态处理对象
*/
private VoteState state = null;
/**
* 记录用户投票的结果,Map<String,String>对应Map<用户名称,投票的选项>
*/
private Map<String,String> mapVote =
new HashMap<String,String>();
/**
* 记录用户投票次数,Map<String,Integer>对应Map<用户名称,投票的次数>
*/
private Map<String,Integer> mapVoteCount =
new HashMap<String,Integer>();
/**
* 获取记录用户投票结果的Map
* @return 记录用户投票结果的Map
*/
public Map getMapVote() {
return mapVote;
}
/**
* 投票
* @param user 投票人,为了简单,就是用户名称
* @param voteItem 投票的选项
*/
public void vote(String user,String voteItem){
//1:先为该用户增加投票的次数
//先从记录中取出已有的投票次数
Integer oldVoteCount = mapVoteCount.get(user);
if(oldVoteCount==null){
oldVoteCount = 0;
}
oldVoteCount = oldVoteCount + 1;
mapVoteCount.put(user, oldVoteCount);
//2:判断该用户投票的类型,就相当于是判断对应的状态
//到底是正常投票、重复投票、恶意投票还是上黑名单的状态
if(oldVoteCount==1){
state = new NormalVoteState();
}else if(oldVoteCount>1 && oldVoteCount<5){
state = new RepeatVoteState();
}else if(oldVoteCount >= 5 && oldVoteCount<8){
state = new SpiteVoteState();
}else if(oldVoteCount>=8){
state = new BlackVoteState();
}
//然后转调状态对象来进行相应的操作
state.vote(user, voteItem, this);
}
}
状态的转换基本上都是内部行为,主要在状态模式内部来维护。比如对于投票的人员,任何时候他的操作都是投票,但是投票管理对象的处理却不一定一样,会根据投票的次数来判断状态,然后根据状态去选择不同的处理。
状态模式的相关小点
1. 状态和行为
状态,通常指的就是对象实例的属性的值;
行为,指的就是对象的功能实现。
状态模式的功能就是分离状态的行为,通过维护状态的变化,来调用不同的状态对应的不同的功能。
状态决定行为。
2. 行为的平行性
平行性指的是各个状态的行为所处的层次是一样的,相互是独立的、没有关联的,是根据不同的状态来决定到底走平行线的那一条,行为是不同的,当然对应的实现也是不同的,相互之间是不可替换的。
平等性强调的是可替换性,大家是同一行为的不同描述或实现,因此在同一个行为发生的时候,可以根据条件来挑选任意一个实现来进行相应的处理。
状态模式和策略模式一个很重要的区别,状态模式的行为是平行性的,不可相互替换的;而策略模式的行为是平等性的,是可以相互替换的。
3. 上下文和状态处理对象
在状态模式中,上下文是持有状态的对象,但是上下文自身并不处理跟状态相关的行为,而是把处理状态的功能委托给了状态对应的状态处理类来处理。
在具体的状态处理类里面经常需要获取上下文自身的数据,甚至在必要的时候会回调上下文的方法,因此,通常将上下文自身当作一个参数传递给具体的状态处理类。
客户端一般只和上下文交互,客户端可以用状态对象来配置一个上下文,一旦配置完毕,就不再需要和状态对象打交道了,客户端通常不负责运行期间状态的维护,也不负责决定到底后续使用哪一个具体的状态处理对象。
4. 不完美的开闭原则
我们可以看出来,状态模式并没有完整的遵守开闭原则。当多出一个状态的时候,上下文类仍然需要新增一个if-else块来进行一定的判断,然后转给新增的状态行为处理类
设计原则是大家在设计和开发中尽量去遵守的,但不是一定要遵守,尤其是完全遵守,在实际开发中,完全遵守那些设计原则几乎是不可能完成的任务。