设计模式-状态模式

概念

优点

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();    }}

控制台输出