状态模式:允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。对象行为型模式
又名状态对象(Objects for States)
用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题
将一个对象的状态从该对象中分离出来,封装到专门的状态类中,使得对象状态可以灵活变化
对于客户端而言,无须关心对象状态的转换以及对象所处的当前状态,无论对于何种状态的对象,客户端都可以一致处理
状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态 的一些列类中,可以把复杂的判断逻辑化。
状态模式包含以下3个角色:
Context(环境类)
State(抽象状态类)
ConcreteState(具体状态类)
典型的抽象状态类代码:
abstract class State
{
//声明抽象业务方法,不同的具体状态类可以有不同的实现
public abstract void Handle();
}
典型的具体状态类代码:
class ConcreteState : State
{
public override void Handle()
{
//方法具体实现代码
}
}
典型的环境类代码:
class Context
{
private State state; //维持一个对抽象状态对象的引用
private int value; //其他属性值,该属性值的变化可能会导致对象状态发生变化
//设置状态对象
public void SetState(State state)
{
this.state = state;
}
public void Request()
{
//其他代码
state.Handle(); //调用状态对象的业务方法
//其他代码
}
public void ChangeState()
{
//判断属性值,根据属性值进行状态转换
if (value == 0)
{
this.SetState(new ConcreteStateA());
}
else if (value == 1)
{
this.SetState(new ConcreteStateB());
}
//……
}
//……
public void ChangeState(Context ctx)
{
//根据环境对象中的属性值进行状态转换
if (ctx.Value == 1)
{
ctx.SetState(new ConcreteStateB());
}
else if (ctx.Value == 2)
{
ctx.SetState(new ConcreteStateC());
}
//......
}
}
某软件公司要为一银行开发一套信用卡业务系统,银行账户(Account)是该系统的核心类之一,通过分析,该软件公司开发人员发现在系统中账户存在3种状态,且在不同状态下账户存在不同的行为,具体说明如下:
(1) 如果账户中余额大于等于0,则账户的状态为正常状态(Normal State),此时用户既可以向该账户存款也可以从该账户取款;
(2) 如果账户中余额小于0,并且大于-2000,则账户的状态为透支状态(Overdraft State),此时用户既可以向该账户存款也可以从该账户取款,但需要按天计算利息;
(3) 如果账户中余额等于-2000,那么账户的状态为受限状态(Restricted State),此时用户只能向该账户存款,不能再从中取款,同时也将按天计算利息;
(4) 根据余额的不同,以上3种状态可发生相互转换。
现使用状态模式设计并实现银行账户状态的转换。
在有些情况下,多个环境对象可能需要共享同一个状态
如果希望在系统中实现多个环境对象共享一个或多个状态对象,那么需要将这些状态对象定义为环境类的静态成员对象
某系统要求两个开关对象要么都处于开的状态,要么都处于关的状态,在使用时它们的状态必须保持一致,开关可以由开转换到关,也可以由关转换到开。
试使用状态模式来实现开关的设计。
开关类:Switch(环境类)
抽象状态类:SwitchState
打开状态类:OnState(具体状态类)
关闭状态类:OffState(具体状态类)
客户端测试类:Program
对于客户端而言,无须关心状态类,可以为环境类设置默认的状态类,将状态的转换工作交给环境类(或具体状态类)来完成,具体的转换细节对于客户端而言是透明的
可以通过环境类来实现状态转换,环境类作为一个状态管理器,统一实现各种状态之间的转换操作
本例子是用来描述开灯关灯状态的
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace 开关灯示例
{
abstract class State
{
public abstract void Handle(Context context);
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace 开关灯示例
{
class Context
{
private State state;
internal State State
{
get
{
return state;
}
set
{
state = value;
Console.WriteLine("当前状态是:{0}",state.GetType().Name);
}
}
public Context(State state)
{
//记录了先前运行的实例 方便Request()使用不同对象中的方法
this.State = state;
}
public void Request()
{
state.Handle(this);
}
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace 开关灯示例
{
class LightOffToOn : State
{
public override void Handle(Context context)
{
context.State = new LightOnToOff();
}
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace 开关灯示例
{
class LightOffToOn : State
{
public override void Handle(Context context)
{
context.State = new LightOnToOff();
}
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace 开关灯示例
{
class Program
{
static void Main(string[] args)
{
Context c = new Context(new LightOnToOff());
c.Request();
c.Request();
c.Request();
c.Request();
}
}
}
状态模式的好处是将特定状态相关的行为局部化,并且将不同状态的行为分割开来
使用状态模式的目的就是消除庞大的条件分支语句,大的分支判断会使得他们难以修改和扩展,就像刻板印刷一样,任何的改动和变化都是致命的。状态模式通过把各种状态转移逻辑分布到State的子类之间,来减少相互间的依赖。这样就成了活字印刷术了。便于维护和扩展了。
封装了状态的转换规则,可以对状态转换代码进行集中管理,而不是分散在一个个业务方法中
将所有与某个状态有关的行为放到一个类中,只需要注入一个不同的状态对象即可使环境对象拥有不同的行为
允许状态转换逻辑与状态对象合成一体,而不是提供一个巨大的条件语句块,可以避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起
可以让多个环境对象共享一个状态对象,从而减少系统中对象的个数
会增加系统中类和对象的个数,导致系统运行开销增大
结构与实现都较为复杂,如果使用不当将导致程序结构和代码混乱,增加系统设计的难度
对开闭原则的支持并不太好,增加新的状态类需要修改负责状态转换的源代码,否则无法转换到新增状态;而且修改某个状态类的行为也需要修改对应类的源代码
当一个对象的行为取决于它的状态的,并且它必须在运行时刻根据状态改变它的行为的时候,就可以考虑使用状态模式了。另外如果业务需求某项业务有多种状态的,通常都是一些枚举变量,状态的变化都是依靠大量的分支判断语句来实现,此时应该考虑将每一种业务状态定义为一个State的子类。这样就可以不依赖于其他对象而独立变化了,某一天客户需要改需求,增加或减少业务状态或改变状态流程,对你来说都不是困难的事儿。
对象的行为依赖于它的状态(例如某些属性值),状态的改变将导致行为的变化
在代码中包含大量与对象状态有关的条件语句,这些条件语句的出现会导致代码的可维护性和灵活性变差,不能方便地增加和删除状态,并且导致客户类与类库之间的耦合增强
本博客部分内容参考了大话设计模式