设计模式`相关文章，用于整理网络中对应的设计模式的一些解读。

举例

以下文字来源于微信公众号（Java知音）文章，设计模式是什么鬼（状态）

状态State，指某事物所处的状况或形态，比如水的三态，零下会变成固态冰，常温会是液态水，100℃会蒸发成气态的水蒸气。

在这个地球生态系统中，水的总量并不会增加，也不会减少，只是随着温度的变化其分子间发生了稀松紧密的变化罢了，于是便有了不同的行为，比如流动、凝固、或是蒸腾，但对于其本质H2O分子对象并没有任何变化，变化的，只是其形态。

图片

当然，事物的状态都是不同的，有的多有的少。物质基本三态，人的精神状态更是非常复杂多变的，喜怒哀乐，五味杂陈。更有趣的是，对于某些患有严重的精神分裂的病人来说，其精神状态更是变化无常，有些竟可以扮演几十种角色，随时间或境遇切换，一会变成精明聪颖的律师，一会是懦弱的失败者总是要自杀，一个境遇触发又是愤怒的杀人暴徒，这人格切换速度，丧心病狂到令人发指。

实例

以下实例来源于微信公众号（Java知音）文章，设计模式是什么鬼（适配器）

开关

实现一个开关类，暴露出两个UI可操作接口（对接你的手指）：开、关。

开关

定义一个类吧，就叫它：Switcher好了，对外暴露两个方法：switchOn()以及switchOff()，以便用户调用。

public class Switcher {
    //false代表关，true代表开
    private boolean state = false;//初始状态是关

    public void switchOn(){
        state = !state;
        System.out.println("OK...灯亮");
    }

    public void switchOff(){
        state = !state;
        System.out.println("OK...灯灭");
    }
}

接口设计完成，没有问题了！！当然说这个没问题是在前端UI壳子设计精妙的前提下，但这并不能代表我们的程序设计没问题。如果UI可以重复调用开或者关会出现什么情况？状态乱套了！这个设计是非常不可靠的，我们不能因为表面设计上的完美就忽略了后端代码功能的逻辑正确性，表里不一。这就是为什么我们做应用时不但要做好前端校验（用户体验），更要保证后端校验（功能正确性）不可缺失。

改一下我们之前的设计，这里一定要加入针对当前状态的条件判断，也就是说，开的状态不能再开，关的状态不能再关！

public class Switcher {
    //false代表关，true代表开
    boolean state = false;//初始状态是关

    public void switchOn(){
        if(state == false){//当前是关状态
            state = true;
            System.out.println("OK...灯亮");
        }else{//当前是开状态
            System.out.println("WARN!!!通电状态无需再开");
        }
    }

    public void switchOff(){
        if(state == true){//当前是开状态
            state = false;
            System.out.println("OK...灯灭");
        }else{//当前是关状态
            System.out.println("WARN!!!断电状态无需再关");
        }
    }
}

这里加入了逻辑判断，如果重复开或者重复关的话是会告警的，当然这里也可以抛异常出去，我们就不搞那么复杂化了。那对于这样的设计没有问题吧？很显然，逻辑上是跑的通的，写个Client类测试一下。

public class Client {

    public static void main(String[] args) {
        Switcher s = new Switcher();
        s.switchOff();//WARN!!!断电状态无需再关
        s.switchOn();//OK...灯亮
        s.switchOff();//OK...灯灭
        s.switchOn();//OK...灯亮
        s.switchOn();//WARN!!!通电状态无需再开
    }

}

So far，不管熊孩子怎么开开关关都不会有问题了。

自动挡

这样的设计仍然是糟糕的。试想，如果状态不止一种，并且状态切换有及其复杂的逻辑，例如：汽车的自动挡。

汽车的自动挡，按照上面的逻辑来设计，就像如下代码：

public class Car {
    //0：Park驻车档，1：Reverse倒退挡，
    //2：Neutral空挡，3：Drive前进档。
    String state = "P";//初始状态是P档

    public void push(){//向上推档杆
        switch (state) {
        case "P"://驻车档状态
            System.out.println("WARN!!!到头了推不动了！");
            break;
        case "R"://倒挡状态
            state = "P";
            System.out.println("OK...切P档");
            break;
        case "N"://空档状态
            System.out.println("OK...切R档");
            break;
        case "D"://前进档状态
            System.out.println("OK...切N档");
            break;
        default:
            break;
        }
    }

    public void pull(){//向下拉档杆
        //这里省略，逻辑同上类似
    }
}

这个是在作死了，那一大堆逻辑判断写在宿主类里会越来越像蜘蛛网！我们必须想方设法把这个设计给模块化，把状态模块给独立出来！可以使用策略模式，将算法策略被抽离出来，这里举一反三，把状态也给抽离出来，好了办法有了，我们忘掉自动挡，继续用我们大道至简的开关例子。

public interface State {
    public void switchOn(Switcher switcher);//开
    public void switchOff(Switcher switcher);//关
}

以上我们首先了定义一个状态State接口，两个方法开与关，注意这里与策略模式不同的是，我们为了与宿主Switcher对接所以把它作为参数传入。然后是开状态与关状态的实现。

public class On implements State {
    @Override
    public void switchOn(Switcher switcher) {
        System.out.println("WARN!!!通电状态无需再开");
        return;
    }

    @Override
    public void switchOff(Switcher switcher) {
        switcher.setState(new Off());
        System.out.println("OK...灯灭");
    }
}
public class Off implements State {
    @Override
    public void switchOn(Switcher switcher) {
        switcher.setState(new On());
        System.out.println("OK...灯亮");
    }

    @Override
    public void switchOff(Switcher switcher) {
        System.out.println("WARN!!!断电状态无需再关");
        return;
    }
}

显而易见，注意看第10行代码，开状态不能做开行为，只告警并返回，关状态反之亦然。而第4行代码则是合法的行为，所以可以进行状态切换并实施相应行为，也就是说，开状态可关，关状态可开。注意这里是把宿主对象传入进来用于切换其当前状态，亦或是调用宿主的具体功能方法（这里省略用打印输出代替），比如宿主里的一盏灯提供的方法。

至此，一切看起来非常优雅，我们已经成功的将状态从宿主中抽离了，最后再来看宿主开关类是什么样子。

public class Switcher {
    //开关的初始状态设置为“关”
    private State state = new Off();

    public State getState() {
        return state;
    }

    public void setState(State state) {
        this.state = state;
    }

    public void switchOn(){
        state.switchOn(this);//这里调用的是当前状态的开方法
    }

    public void switchOff(){
        state.switchOff(this);//这里调用的是当前状态的关方法
    }
}

甚至我们还可以给里面加一盏灯，像之前我们提到的那样，在State状态接口实现里去调用。

public class Switcher {
    //...之上代码略...
    private Lamp lamp;

    public void lampOn(){
        lamp.on();
    }

    public void lampOff(){
        lamp.off();
    }
}

其实它就是策略的一个变种，只不过状态模式会更好的根据当前的状态去实施不同的行为，并且自主切换到另一个正确的状态，开变关，关变开。就好似电梯（虽然是嵌入式面向过程，这里只是举例），用户根本无法随意强制更改其状态以及行为，你让它上，它不一定马上就能上，否则会造成事故。电梯内部封装了多个状态以及对应的逻辑产生不同的行为，它会根据当前状态去自我调整并实施最优方案，以达到安全、高效的目的，这才是可靠的设计。

注意事项：在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。