设计模式-状态模式

设计模式-状态模式

概念

优点

1、封装了转换规则。 

2、枚举可能的状态，在枚举状态之前需要确定状态种类。 

3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 

4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 

5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

缺点

1、状态模式的使用必然会增加系统类和对象的个数。 

2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 

3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。

使用场景

1.一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。
2.一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态。

角色

AbstractState :抽象状态

ConreteState:具体状态

Context ：带有某个状态的类

UML类图

代码解析UML类图

AbstractState :抽象状态：

/**
 * 设计模式-状态模式-抽象状态（气侯状态）
 *
 * 这里抽象人类在不同的气侯状态下，人类的行为（所说的话）
 *
 * Created by laizhiyuan on 2017/6/12.
 */
public abstract class AbstarctWeatherState {

    /**
     * 这里入参一个关联该状态的对象
     *
     * 当前状态对象的行为，这里是说一句话
     */
    public abstract void say(People people);
}

ConreteState:具体状态

/**
 * 设计模式-状态模式-具体状态（春天状态）
 *
 * Created by laizhiyuan on 2017/6/12.
 */
public class SpringWeatherState extends AbstarctWeatherState {


    @Override
    public void say(People people) {

        System.out.println("春天来了，天气有点闷!");

        /**
         * 春天过后转入夏天转态，这里按需求实现自己的转态改变
         *
         * 比如订单：
         *
         * 加入购物车-付款-收货-评价
         */
        people.abstarctWeatherState = new SummerWeatherState();

    }
}

/**
 * 设计模式-状态模式-具体状态（夏天状态）
 *
 * Created by laizhiyuan on 2017/6/12.
 */
public class SummerWeatherState extends AbstarctWeatherState{

    @Override
    public void say(People people) {

        System.out.println("夏天来了，热的不要不要的");

        /**
         * 夏天过后转入秋天转态，这里按需求实现自己的转态改变
         *
         * 比如订单：
         *
         * 加入购物车-付款-收货-评价
         */
        people.abstarctWeatherState = new AutumnWeatherState();
    }
}

/**
 * 设计模式-状态模式-具体状态（秋天状态）
 *
 * Created by laizhiyuan on 2017/6/12.
 */
public class AutumnWeatherState extends AbstarctWeatherState{

    @Override
    public void say(People people) {

        System.out.println("秋天来了，非常凉爽");

    }
}

Context ：带有某个状态的类

/**
 * 设计模式-状态模式-状态对象
 *
 * Created by laizhiyuan on 2017/6/12.
 */
public class People {

    /**
     * 状态抽象/接口类
     */
    public AbstarctWeatherState abstarctWeatherState;


    /**
     * 强制入参初始化时的状态,这里可以不作为参数入参，直接再方法体中写死
     * 如注释中所示
     *
     * @param abstarctWeatherState
     */
    public People(AbstarctWeatherState abstarctWeatherState) {

        /**
         * 另一种初始化方式
         */
        //abstarctWeatherState = new SpringWeatherState();

        this.abstarctWeatherState = abstarctWeatherState;
    }

    /**
     * 人类在不同的气温状态下，所说的话
     */
    public void request(){

        /**
         * 由不同气温下的状态去实现，对象和状态分离的实现
         */
        abstarctWeatherState.say(this);
    }
}

测试

/**
 * 测试
 *
 * Created by lzy on 2017/6/12.
 */
public class Main {


    /**
     *
     * 问：如果需要添加一个状态，（如冬天状态）怎么做，会影响其它类吗
     * 答：加个冬天状态类，参照其它的转态实现say()方法，不需要修改其它类，符合开闭原则
     *      但是如果内部转态转换是写死在状态对象中，如本次春天-夏天是写死的流程
     *      ，当要改变这个流程时，就会违背开闭原则，这个需要注意
     *
     * 问：如果不使用状态模式的话，怎么实现这个功能，有什么弊端
     * 答：通常采用if else 或者switch 方式判断进行对象的不同行为，在以后需要添加新的
     *      状态时需要修改或增加分支，违背开闭原则，而且如果其它对象也需要同样的状态是，不能复用
     *
     * @param args
     */
    public static void main(String[] args) {


        /**
         * 假设初始化状态为为春天气候
         */
        AbstarctWeatherState initState = new SpringWeatherState();
        People people = new People(initState);

        /**
         * 不断请求，改变转态在状态类中定义了流程 春天-夏天-秋天
         *
         * 实际项目中可以灵活改版，不是强制需要流程化的
         *
         * 可以提供一个设置转态的方法让客户端自己入参什么转态，这样好处是灵活通用，
         * 不好的是需要客户端了解状态的类
         */
        people.request();
        people.request();
        people.request();



    }
}

控制台输出