设计模式-状态模式实现状态机
2016-05-31 13:34
295 查看
1.概述
在软件开发过程中,应用程序可能会根据不同的情况作出不同的处理。最直接的解决方案是将这些所有可能发生的情况全都考虑到。然后使用if... ellse语句来做状态判断来进行不同情况的处理。但是对复杂状态的判断就显得“力不从心了”。随着增加新的状态或者修改一个状体(if
else(或switch case)语句的增多或者修改)可能会引起很大的修改,而程序的可读性,扩展性也会变得很弱。维护也会很麻烦。那么我就考虑只修改自身状态的模式。
2.组成
环境类(Context): 定义客户感兴趣的接口。维护一个ConcreteState子类的实例,这个实例定义当前状态。
抽象状态类(State): 定义一个接口以封装与Context的一个特定状态相关的行为。
具体状态类(ConcreteState): 每一子类实现一个与Context的一个状态相关的行为。
3.应用
在下面的两种情况下均可使用State模式:
1) • 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
2) • 代码中包含大量与对象状态有关的条件语句:一个操作中含有庞大的多分支的条件(if
else(或switch case)语句,且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常 , 有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化。
4.结构
5.优缺点
状态模式的优点:
1 ) 它将与特定状态相关的行为局部化,并且将不同状态的行为分割开来: State模式将所有与一个特定的状态相关的行为都放入一个对象中。因为所有与状态相关的代码都存在于某一个State子类中, 所以通过定义新的子类可以很容易的增加新的状态和转换。另一个方法是使用数据值定义内部状态并且让 Context操作来显式地检查这些数据。但这样将会使整个Context的实现中遍布看起来很相似的条件if else语句或switch case语句。增加一个新的状态可能需要改变若干个操作,
这就使得维护变得复杂了。State模式避免了这个问题, 但可能会引入另一个问题, 因为该模式将不同状态的行为分布在多个State子类中。这就增加了子类的数目,相对于单个类的实现来说不够紧凑。但是如果有许多状态时这样的分布实际上更好一些, 否则需要使用巨大的条件语句。正如很长的过程一样,巨大的条件语句是不受欢迎的。它们形成一大整块并且使得代码不够清晰,这又使得它们难以修改和扩展。 State模式提供了一个更好的方法来组织与特定状态相关的代码。决定状态转移的逻辑不在单块的 i f或s w i t c h语句中,
而是分布在State子类之间。将每一个状态转换和动作封装到一个类中,就把着眼点从执行状态提高到整个对象的状态。这将使代码结构化并使其意图更加清晰。
2) 它使得状态转换显式化: 当一个对象仅以内部数据值来定义当前状态时 , 其状态仅表现为对一些变量的赋值,这不够明确。为不同的状态引入独立的对象使得转换变得更加明确。而且, State对象可保证Context不会发生内部状态不一致的情况,因为从 Context的角度看,状态转换是原子的—只需重新绑定一个变量(即Context的State对象变量),而无需为多个变量赋值
3) State对象可被共享 如果State对象没有实例变量—即它们表示的状态完全以它们的类型来编码—那么各Context对象可以共享一个State对象。当状态以这种方式被共享时, 它们必然是没有内部状态, 只有行为的轻量级对象。
状态模式的缺点:
1) 状态模式的使用必然会增加系统类和对象的个数。
2) 状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。
6.代码实现
//抽象状态
public abstract class State {//状态:black->red->blue->green-black
public abstract void push(Context context);//下一个状态
public abstract void pull(Context context);//上一个状态
public abstract String getColor();
}
//黑色状态
public class BlackState extends State{
@Override
public void pull(Context context) {
context.setState(new GreenState());
}
@Override
public void push(Context context) {
context.setState(new RedState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "BLACK";
}
}
//蓝色状态
public class BlueState extends State{
@Override
public void pull(Context context) {
context.setState(new RedState());
}
@Override
public void push(Context context) {
context.setState(new GreenState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "BLUE";
}
}
//绿色状态
public class GreenState extends State{
@Override
public void pull(Context context) {
context.setState(new BlueState());
}
@Override
public void push(Context context) {
context.setState(new BlackState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "GREEN";
}
}
//红色状态
public class RedState extends State{
@Override
public void pull(Context context) {
context.setState(new BlackState());
}
@Override
public void push(Context context) {
context.setState(new BlueState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "RED";
}
}
//环境类
public class Context {
private State state;
public void setState(State state){
this.state = state;
}
public void push(){
state.push(this);
System.out.println("push:"+state.getColor());
}
public void pull(){
state.pull(this);
System.out.println("pull:"+state.getColor());
}
}
//测试类
public static void main(String[] args) {
Context context = new Context();
context.setState(new BlackState());//初始化状态为黑色
context.push();
context.push();
context.push();
context.push();
context.push();
context.push();
}
打印结果:
push:RED
push:BLUE
push:GREEN
push:BLACK
push:RED
push:BLUE
在软件开发过程中,应用程序可能会根据不同的情况作出不同的处理。最直接的解决方案是将这些所有可能发生的情况全都考虑到。然后使用if... ellse语句来做状态判断来进行不同情况的处理。但是对复杂状态的判断就显得“力不从心了”。随着增加新的状态或者修改一个状体(if
else(或switch case)语句的增多或者修改)可能会引起很大的修改,而程序的可读性,扩展性也会变得很弱。维护也会很麻烦。那么我就考虑只修改自身状态的模式。
2.组成
环境类(Context): 定义客户感兴趣的接口。维护一个ConcreteState子类的实例,这个实例定义当前状态。
抽象状态类(State): 定义一个接口以封装与Context的一个特定状态相关的行为。
具体状态类(ConcreteState): 每一子类实现一个与Context的一个状态相关的行为。
3.应用
在下面的两种情况下均可使用State模式:
1) • 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
2) • 代码中包含大量与对象状态有关的条件语句:一个操作中含有庞大的多分支的条件(if
else(或switch case)语句,且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常 , 有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化。
4.结构
5.优缺点
状态模式的优点:
1 ) 它将与特定状态相关的行为局部化,并且将不同状态的行为分割开来: State模式将所有与一个特定的状态相关的行为都放入一个对象中。因为所有与状态相关的代码都存在于某一个State子类中, 所以通过定义新的子类可以很容易的增加新的状态和转换。另一个方法是使用数据值定义内部状态并且让 Context操作来显式地检查这些数据。但这样将会使整个Context的实现中遍布看起来很相似的条件if else语句或switch case语句。增加一个新的状态可能需要改变若干个操作,
这就使得维护变得复杂了。State模式避免了这个问题, 但可能会引入另一个问题, 因为该模式将不同状态的行为分布在多个State子类中。这就增加了子类的数目,相对于单个类的实现来说不够紧凑。但是如果有许多状态时这样的分布实际上更好一些, 否则需要使用巨大的条件语句。正如很长的过程一样,巨大的条件语句是不受欢迎的。它们形成一大整块并且使得代码不够清晰,这又使得它们难以修改和扩展。 State模式提供了一个更好的方法来组织与特定状态相关的代码。决定状态转移的逻辑不在单块的 i f或s w i t c h语句中,
而是分布在State子类之间。将每一个状态转换和动作封装到一个类中,就把着眼点从执行状态提高到整个对象的状态。这将使代码结构化并使其意图更加清晰。
2) 它使得状态转换显式化: 当一个对象仅以内部数据值来定义当前状态时 , 其状态仅表现为对一些变量的赋值,这不够明确。为不同的状态引入独立的对象使得转换变得更加明确。而且, State对象可保证Context不会发生内部状态不一致的情况,因为从 Context的角度看,状态转换是原子的—只需重新绑定一个变量(即Context的State对象变量),而无需为多个变量赋值
3) State对象可被共享 如果State对象没有实例变量—即它们表示的状态完全以它们的类型来编码—那么各Context对象可以共享一个State对象。当状态以这种方式被共享时, 它们必然是没有内部状态, 只有行为的轻量级对象。
状态模式的缺点:
1) 状态模式的使用必然会增加系统类和对象的个数。
2) 状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。
6.代码实现
//抽象状态
public abstract class State {//状态:black->red->blue->green-black
public abstract void push(Context context);//下一个状态
public abstract void pull(Context context);//上一个状态
public abstract String getColor();
}
//黑色状态
public class BlackState extends State{
@Override
public void pull(Context context) {
context.setState(new GreenState());
}
@Override
public void push(Context context) {
context.setState(new RedState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "BLACK";
}
}
//蓝色状态
public class BlueState extends State{
@Override
public void pull(Context context) {
context.setState(new RedState());
}
@Override
public void push(Context context) {
context.setState(new GreenState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "BLUE";
}
}
//绿色状态
public class GreenState extends State{
@Override
public void pull(Context context) {
context.setState(new BlueState());
}
@Override
public void push(Context context) {
context.setState(new BlackState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "GREEN";
}
}
//红色状态
public class RedState extends State{
@Override
public void pull(Context context) {
context.setState(new BlackState());
}
@Override
public void push(Context context) {
context.setState(new BlueState());
}
@Override
public String getColor() {
// TODO Auto-generated method stub
return "RED";
}
}
//环境类
public class Context {
private State state;
public void setState(State state){
this.state = state;
}
public void push(){
state.push(this);
System.out.println("push:"+state.getColor());
}
public void pull(){
state.pull(this);
System.out.println("pull:"+state.getColor());
}
}
//测试类
public static void main(String[] args) {
Context context = new Context();
context.setState(new BlackState());//初始化状态为黑色
context.push();
context.push();
context.push();
context.push();
context.push();
context.push();
}
打印结果:
push:RED
push:BLUE
push:GREEN
push:BLACK
push:RED
push:BLUE
相关文章推荐
- [老文章搬家] [翻译] 深入解析win32 crt 调试堆
- sqlserver查询树表某个节点所有的子节点
- 第十四周项目2-两个成员的类模板(1)
- Greta 入门指南
- 第十三周项目3形状类族中的纯虚函数
- Linux如何查看进程、杀死进程、启动进程等常用命令
- 高德地图添加点击手势不响应
- scrollLoading插件实现图片延迟懒加载实例包涵html和js代码
- Sign in - CodeProject
- 第二阶段—个人工作总结09
- 第14周-项目2-两个成员的类模板(1)
- Linux下进程的内存相关信息的查看
- Kafka入门经典教程
- Android设计模式之代理模式(Proxy Pattern)
- 输入一棵二元树,从上往下按层打印每个节点,每层从左往右打印。利用队列。
- SetACL 使用方法详细参数中文解析
- Java基础回顾 : 对象序列化和反序列化
- LOG规范
- iOS Error = NSURLErrorDomain Code=-1022
- 据说看完这21个故事的人,30岁前都成了亿万富翁。你是下一个吗?