设计模式学习笔记(十五)—State模式

一、State模式定义:

允许一个对象在其状态改变时,改变它的行为。看起来对象似乎修改了它的类。

二、模式解说

State模式主要解决的是在开发中时常遇到的根据不同的状态需要进行不同的处理操作的问题,而这样的问题,大部分人是采用switch-case语句进行处理的,这样会造成一个问题:分支过多,而且如果加入一个新的状态就需要对原来的代码进行编译。State模式采用了对这些不同的状态进行封装的方式处理这类问题,当状态改变的时候进行处理然后再切换到另一种状态,也就是说把状态的切换责任交给了具体的状态类去负责.同时,State模式和Strategy模式有很多相似的地方,需要说明的是两者的思想都是一致的,只不过封装的东西不同:State模式封装的是不同的状态,而Stategy模式封装的是不同的算法。

三、结构图

State模式结构图如下:

四、怎么使用?

1)定义一个State接口,接口中有一个统一的方法,用以封装一个特定状态所对应的行为。

2)定义具体不同状态类ConcreteSate实现State接口。

3)每一个状态类都实现环境(Context)一个状态所对应的行为。

4)定义一个状态管理器Context.

五、一个例子

interface State{
public void handle(Context ctx);
}
class ConcreteStateA implements State{

public void handle(Context ctx) {
 System.out.println("handle by ConcreteStateA");
 if(ctx!=null){
 ctx.ChangeState(new ConcreteStateB());
 }

}
}
class ConcreteStateB implements State{

public void handle(Context ctx) {
 System.out.println("handle by ConcreteStateB");
 if(ctx!=null){
 ctx.ChangeState(new ConcreteStateA());
 }

}
}
class Context{
private State _state;
public Context(State state){
 _state=state;
}
public void request(){
 if(_state!=null){
 _state.handle(this);
 }
}
public void ChangeState(State s){
 if(_state!=null){
 _state=null;
 }
 _state=s;
}
}
public class StateClient {

public static void main(String[] args) {
 State state=new ConcreteStateA();
 Context context=new Context(state);
 context.request();
 context.request();
 context.request();
 context.request();

}

}

时间: 2024-08-03 17:35:51

设计模式学习笔记(十五)—State模式的相关文章

设计模式学习笔记(十)—Factory Method模式

<设计模式>一书对Factory Method模式是这样描述的: 定义一个用于创建对象的接口,让子类决定实例化哪一个类.FactoryMethod使一个类的实例化延迟到其子类. 我的理解:FatoryMethod模式是一种创建型模式,定义一个用于创建对象的接口的意思是说,我们要定义一个用于创建对象的接口(或者说抽象类,实际上就是个抽象工厂abstractFactory),它的内部有一个创建对象的方法,这个方法的返回值是一个接口(或者抽象类)的类型,这个方法就是FactoryMethod:让子类

设计模式学习笔记(十六)—Proxy模式

一.Proxy模式定义: 为其他对象提供一种代理以控制这个对象的访问. 二.模式解说 Proxy代理模式是一种结构型设计模式,主要解决的问题是:在直接访问对象时带来的问题,比如说:要访问的对象在远程的机器上.在面向对象系统中,有些对象由于某些原因(比如对象创建开销很大,或者某些操作需要安全控制,或者需要进程外的访问),直接访问会给使用者或者系统结构带来很多麻烦,我们可以在访问此对象时加上一个对此对象的访问层,这个访问层也叫代理.Proxy模式是最常见的模式,在我们生活中处处可见,例如我们买火车票

设计模式学习笔记(十四)—Command模式

一.Command模式定义: 将一个请求封装为一个对象,从而使你不同的请求对客户进行参数化:对请求排队或记录请求日志,以及支持可撤销的操作. 二.模式解说 Commad模式是一种对象行为模式,它可以对发送者(sender)和接收者(receiver)完全解耦(decoupling).("发送者" 是请求操作的对象,"接收者" 是接收请求并执行某操作的对象.有了 "解耦",发送者对接收者的接口一无所知.)这里,"请求"(requ

kvm虚拟化学习笔记(十五)之kvm虚拟机动态迁移

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://koumm.blog.51cto.com/703525/1300783 相比KVM虚拟机静态迁移中需要拷贝虚拟机虚拟磁盘文件,kvm虚拟机动态迁移无需拷贝虚拟磁盘文件,但是需要迁移到的虚拟主机之间需要有相同的目录结构虚拟机磁盘文件,本文这部分内容通过nfs来实现,当然也可以采用GFS2集群文件系统来实现,本文的动态迁移是基于共享存储动态迁移. KVM动态迁移目前有两种,一种是基于

设计模式学习笔记(三)—-Strategy策略模式

GOF<设计模式>一书对Strategy模式是这样描述的: 定义一系列的算法,把他们一个个封装起来,并且使它们可相互替换.Strategy模式使算法可独立于使用它的客户而变化. Strategy模式以下列几条原则为基础: 1)每个对象都是一个具有职责的个体. 2)这些职责不同的具体实现是通过多态的使用来完成的. 3)概念上相同的算法具有多个不同的实现,需要进行管理. 下面我将通过一个实例来说明它的具体使用,这个例子是关于数据库连接的.代码如下: interface DatabaseStrate

设计模式学习笔记(一) Facade外观模式

GOF<设计模式>一书对Facade模式是这样描述的: 为子系统中的一组接口提供一个统一接口.Facade模式定义了一个更高层的接口,使子系统更加容易使用. 大致意思是说:使用一种比原有方式更简单的办法与系统交互.例如,我们把一个很文件的文件,放在了第二抽屉里,而第二个抽屉的钥匙放在了第一个抽屉里,我们要想取出这个文件,第一步肯定要拿到第一个抽屉的钥匙,然后打开它再拿出第二个抽屉的钥匙,最后打开第二个抽屉取出文件. 我就上面说的那个情形写一下实现代码,首先我们要实现二个子系统,呵呵,把抽屉比喻

hibernate3学习笔记(十五)|继承映射

这里详细讨论继承映射的3种方式: 1.Table per concrete class 继承关系如下图: 数据表设计如下图: MySQL数据库中执行如下DDL: 1.CREATE TABLE defaultuser (2. id INT(11) NOT NULL auto_increment PRIMARY KEY,3. name VARCHAR(100) NOT NULL default '',4. someProperty VARCHAR(100)5.);6.7.CREATE TABLE p

设计模式学习笔记(十九)—Chain of Responsibility职责链模式

由于本人水平有限,写出来的东西也许对初学者有所帮助.如果不小心哪位大侠看了不要见笑,哪里有不正确的地方还请批评指正.好了不说废话了. Chain of Responsibility模式定义: 为了避免请求的发送者和接收者之间的耦合关系,使多个接受对象都有机会处理请求.将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止. 我的理解: 在不止一个对象可以处理客户端请求的时候,为了使每个对象都有处理请求的机会,把这些对象顺序地串联起来形成一个链,每个被串联的对象都有一个指向下一个对

设计模式学习笔记(十八)—Mediator中介者模式

一.模式定义: 用一个中介者对象来封装一系列的对象交互.中介者使各对象不需要显式的相互引用,从而使其耦合松散,而且可以独立的改变他们之间的交互. 二.结构图 1) 抽象中介者:定义同事(Colleague)对象到中介者(Mediatior)对象的接口,通常是一个事件方法. 2) 具体中介者:具体中介者实现抽象中介者声明的方法.知晓所有的具体同事类,从具体同事接收消息向另外的具体同事类发送命令. 3) 抽象同事类:定义中介者到同事对象的接口,同事对象只知道中介者而不知道其他同事对象. 三.一个例子