林炳文Evankaka原创作品。转载请注明出处http://blog.csdn.net/evankaka
一、状态模式
1、定义
状态模式 :允许一个对象在其内部状态改变时改变它的行为,即不同的状态对应不同的行为。 这需要将状态单独抽象成一个对象。
2、意图
4、模式中的角色
上下文环境(Context):它定义了客户程序需要的接口并维护一个具体状态角色的实例,将与状态相关的操作委托给当前的Concrete State对象来处理。
抽象状态(State):定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。
具体状态(Concrete State):实现抽象状态定义的接口。
5、适用性
在下面的两种情况下均可使用State模式:
(1)一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
(2)代码中包含大量与对象状态有关的条件语句:一个操作中含有庞大的多分支的条件(if else(或switch case)语句,且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常 , 有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化。
二、使用范例
//灯的类
public class Light {
private LightState m_state;//灯的状态
/*初始化为一个灯的颜色*/
public Light(LightState m_state){
this.m_state=m_state;
}
/*改变灯的颜色*/
public void setLight(LightState m_state) {
this.m_state=m_state;
}
/*得到当前灯的颜色*/
public void lightColor(){
m_state.lightColor(this);
}
}
//灯的颜色抽象接口
public interface LightState {
/*改变灯*/
public abstract void lightColor(Light m_litht);
}
//红灯
public class RedState implements LightState {
@Override
public void lightColor(Light m_light) {
System.out.println("红灯亮了");
m_light.setLight(new GreenLight());//红灯亮完,设置为绿灯
}
}
//绿灯
public class GreenLight implements LightState {
@Override
public void lightColor(Light m_light) {
System.out.println("绿灯亮了");
m_light.setLight(new YellowState());//绿灯亮完,设置为黄灯
}
}
//黄灯
public class YellowState implements LightState {
@Override
public void lightColor(Light m_light) {
System.out.println("黄灯亮了");
m_light.setLight(new RedState());//黄灯亮完,设置为红灯
}
}
/**
* 文件名:Main.java
* 描述:状态讲解
* 创建人:林炳文
* 日 期:2015.1.27
**/
public class Main {
public static void main(String[] args) {
LightState m_LightState=new RedState();//灯初始货为红色
Light m_light=new Light(m_LightState);
m_light.lightColor();//输出当前灯颜色,并改变下次输出灯的颜色
m_light.lightColor();
m_light.lightColor();
m_light.lightColor();
}
}
输出:
红灯亮了
绿灯亮了
黄灯亮了
红灯亮了
三、优缺点
1、优点
(1)状态模式将与特定状态相关的行为局部化,并且将不同状态的行为分割开来。
(2)所有状态相关的代码都存在于某个ConcereteState中,所以通过定义新的子类很容易地增加新的状态和转换。
(3)状态模式通过把各种状态转移逻辑分不到State的子类之间,来减少相互间的依赖。
2、缺点
(1)状态模式的使用必然会增加系统类和对象的个数。
(2)状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。
四、与策略模式区别
1、相似之处:
- 添加新的状态或策略都很容易,而且不需要修改使用它们的Context对象。
- 它们都让你的代码符合OCP原则。在状态模式和策略模式中,Context对象对修改是关闭的,添加新的状态或策略,都不需要修改Context。
- 正如状态模式中的Context会有初始状态一样,策略模式同样有默认策略。
- 状态模式以不同的状态封装不同的行为,而策略模式以不同的策略封装不同的行为。
- 它们都依赖子类去实现相关行为。
2、不同之处
现在我们知道,状态模式和策略模式的结构是相似的,但它们的意图不同。让我们重温一下它们的主要不同之处:
- 策略模式封装了一组相关算法,它允许Client在运行时使用可互换的行为;状态模式帮助一个类在不同的状态显示不同的行为。
- 状态模式封装了对象的状态,而策略模式封装算法或策略。因为状态是跟对象密切相关的,它不能被重用;而通过从Context中分离出策略或算法,我们可以重用它们。
- 在状态模式中,每个状态通过持有Context的引用,来实现状态转移;但是每个策略都不持有Context的引用,它们只是被Context使用。
- 策略实现可以作为参数传递给使用它的对象,例如Collections.sort(),它的参数包含一个Comparator策略。另一方面,状态是Context对象自己的一部分,随着时间的推移,Context对象从一个状态转移到另一个状态。
- 虽然它们都符合OCP原则,策略模式也符合SRP原则(单一职责原则),因为每个策略都封装自己的算法,且不依赖其他策略。一个策略的改变,并不会导致其他策略的变化。
- 另一个理论上的不同:策略模式定义了对象“怎么做”的部分。例如,排序对象怎么对数据排序。状态模式定义了对象“是什么”和“什么时候做”的部分。例如,对象处于什么状态,什么时候处在某个特定的状态。
- 状态模式中很好的定义了状态转移的次序;而策略模式并无此需要:Client可以自由的选择任何策略。
- 一些常见的策略模式的例子是封装算法,例如排序算法,加密算法或者压缩算法。如果你看到你的代码需要使用不同类型的相关算法,那么考虑使用策略模式吧。而识别何时使用状态模式是很简单的:如果你需要管理状态和状态转移,但不想使用大量嵌套的条件语句,那么就是它了。
- 最后但最重要的一个不同之处是,策略的改变由Client完成;而状态的改变,由Context或状态自己。