设计模式-状态模式实现状态机

原创 2016年05月31日 13:34:51

      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










版权声明:本文为博主原创文章,未经博主允许不得转载。转载请注明来自:http://blog.csdn.net/wuqingyidongren

设计模式之状态机模式

ZT From :http://www.jdon.com/designpatterns/designpattern_State.htm State模式的定义: 不同的状态,不同的行为;或者说,每个状...
  • mfc11
  • mfc11
  • 2013年11月24日 17:47
  • 20586

Java与设计模式-状态模式

概念:状态模式把所研究的对象的行为包装在不同的状态对象里,每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候,其行为也随之改变,也就是不同状态对应不同的行为...
  • yayun0516
  • yayun0516
  • 2016年03月08日 11:42
  • 1679

Java 设计模式——状态模式

很多人在说状态模式的时候总拿策略模式来进行对比,可能他们的类图会有一点类似,可我却不认为他们有多么相像。你可以阅读《Java设计模式——策略模式》这篇博客,并与本文对比,以找到蛛丝马迹。 他们最根本的...
  • u013761665
  • u013761665
  • 2016年06月06日 16:46
  • 8314

Java设计模式之状态模式

本文属于"23种设计模式"系列,介绍状态模式。
  • jason0539
  • jason0539
  • 2015年04月14日 07:54
  • 14495

基于继承实现的状态依赖并发控制

1> 由非公共方法来定义功能,由公共方法来定义并发控制的策略。2> 可以使子类能够独立地对执行功能的代码或者执行并发控制的代码进行修改,从而使得子类无需修改所有父类的方法就可以得到所需的功能3> 避免...
  • blueheart20
  • blueheart20
  • 2007年05月14日 15:58
  • 614

状态模式实现依赖于状态的行为

应用场景描述: 一个开关可以被pull或者push,共有三种不同的颜色,称为状态,每种不同的颜色下执行push或者pull得到的下一个状态不同,即一个有穷状态机,对不同的输入有不同的响应。因为状态改变...
  • sinapme
  • sinapme
  • 2013年12月17日 14:52
  • 384

FSM状态机

基本解析: 比如说一个人有多种状态(站着,说话,跑,攻击等),而人想要执行的动作全部由大脑控制执行的,大脑支配人的走,跑,所以大脑就相当于人执行动作的一个工具(FSM),这个工具连接着各种行为,而每...
  • GaoHeShun
  • GaoHeShun
  • 2017年03月24日 19:59
  • 439

个人对23种设计模式总结 优缺点分析

在看了《大话设计模式》一书后,总结了一些笔记,如下: 关于设计模式的总结 1.抽象工厂: Factory 提供一个创建一系列或相关依赖对象的接口,而无需指定他们具体的类。针对多级...
  • wanglingxxx
  • wanglingxxx
  • 2016年10月19日 15:24
  • 2431

[python]有限状态机(FSM)简单实现

本文发表于恋花蝶的博客http://blog.csdn.net/lanphaday,欢迎转载,但必须保留文章内容完整且包含本声明。违者必究。 [python]有限状态机(FSM)简单实现简述 有限状...
  • csdn_sr
  • csdn_sr
  • 2016年07月15日 09:51
  • 312

设计模式 ( 十七) 状态模式State(对象行为型)

设计模式 ( 十七) 状态模式State(对象行为型) 1.概述 在软件开发过程中,应用程序可能会根据不同的情况作出不同的处理。最直接的解决方案是将这些所有可能发生的情况全都考虑到。然...
  • hguisu
  • hguisu
  • 2012年05月11日 17:26
  • 81856
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:设计模式-状态模式实现状态机
举报原因:
原因补充:

(最多只允许输入30个字)