状态模式

Published on 2016 - 09 - 03

应用示例

现在城市发展很快,百万级人口的城市很多,那其中有两个东西的发明在城市的发展中起到非常重要的作用:一个是汽车,另一个是电梯。汽车让城市可以横向扩展,电梯让城市可以纵向延伸,向空中伸展。汽车对城市的发展我们就不说了,电梯,你想想看,如果没有电梯,每天你需要爬15层楼梯,你是不是会累坏了?建筑师设计了一个没有电梯的建筑,投资者肯定不愿意投资,那也是建筑师的耻辱,今天我们就用程序表现一下这个电梯是怎么运作的。

我们每天都在乘电梯,那我们来看看电梯有哪些动作(映射到Java中就是有多少方法):开门、关门、运行、停止。好,我们就用程序来实现一下电梯的动作,先看类图设计,如图1所示。

非常简单的类图,定义一个接口,然后是一个实现类,然后业务场景类Client就可以调用,并运行起来,简单也要实现出来。看看该程序的接口,如代码清单1所示。

public interface ILift {
     //首先电梯门开启动作
     public void open();
     //电梯门可以开启,那当然也就有关闭了
     public void close();
     //电梯要能上能下
     public void run();
     //电梯还要能停下来
     public void stop();
}

接口有了,再来看实现类,如代码清单2所示。

public class Lift implements ILift {
     //电梯门关闭
     public void close() {
             System.out.println("电梯门关闭...");
     }
     //电梯门开启
     public void open() {
             System.out.println("电梯门开启...");
     }
     //电梯开始运行起来
     public void run() {
             System.out.println("电梯上下运行起来...");
     }
    //电梯停止
     public void stop() {
             System.out.println("电梯停止了...");
     }
}

电梯的开、关、运行、停都实现了,再看看场景类是怎么调用的,如代码清单3所示。

public class Client {
     public static void main(String[] args) {
             ILift lift = new Lift();
             //首先是电梯门开启,人进去
             lift.open();
             //然后电梯门关闭
             lift.close();
             //再然后,电梯运行起来,向上或者向下
             lift.run();
             //最后到达目的地,电梯停下来
             lift.stop();
     }
}

运行的结果如下所示:

电梯门开启...
电梯门关闭...
电梯上下运行起来...
电梯停止了...

太简单的程序了!每个程序员都会写这个程序,这么简单的程序还拿出来显摆,是不是太小看我们的智商了?非也,非也,我们继续往下分析,这个程序有什么问题?你想想,电梯门可以打开,但不是随时都可以开,是有前提条件的。你不可能电梯在运行的时候突然开门吧?!电梯也不会出现停止了但是不开门的情况吧?!那要是有也是事故嘛,再仔细想想,电梯的这4个动作的执行都有前置条件,具体点说就是在特定状态下才能做特定事,那我们来分析一下电梯有哪些特定状态。

  • 敞门状态

按了电梯上下按钮,电梯门开,这中间大概有10秒的时间,那就是敞门状态。在这个状态下电梯只能做的动作是关门动作。

  • 闭门状态

电梯门关闭了,在这个状态下,可以进行的动作是:开门(我不想坐电梯了)、停止(忘记按路层号了)、运行。

  • 运行状态

电梯正在跑,上下窜,在这个状态下,电梯只能做的是停止。

  • 停止状态

电梯停止不动,在这个状态下,电梯有两个可选动作:继续运行和开门动作。

我们用一张表来表示电梯状态和动作之间的关系,如图2所示(○表示不允许,☆表示允许动作)。

看到这张表后,我们才发觉,哦,我们的程序做得很不严谨,好,我们来修改一下,如图3所示。

在接口中定义了4个常量,分别表示电梯的4个状态:敞门状态、闭门状态、运行状态、停止状态,然后在实现类中电梯的每一次动作发生都要对状态进行判断,判断是否可以执行,也就是动作的执行是否符合业务逻辑,实现类中有4个私有方法是仅仅实现电梯的动作,没有任何前置条件,因此这4个方法是不能为外部类调用的,设置为私有方法。我们先看接口的改变,如代码清单4所示。

public interface ILift {
     //电梯的4个状态
     public final static int OPENING_STATE = 1;  //敞门状态
     public final static int CLOSING_STATE = 2;  //闭门状态
     public final static int RUNNING_STATE = 3;  //运行状态
     public final static int STOPPING_STATE = 4; //停止状态
     //设置电梯的状态
     public void setState(int state);
     //首先电梯门开启动作
     public void open();
     //电梯门可以开启,那当然也就有关闭了
     public void close();
     //电梯要能上能下,运行起来
     public void run();
     //电梯还要能停下来
     public void stop();
}

这里增加了4个静态常量,并增加了一个方法setState,设置电梯的状态。我们再来看实现类是如何实现的,如代码清单5所示。

public class Lift implements ILift {
     private int state;
     public void setState(int state) {
             this.state = state;
     }
     //电梯门关闭
     public void close() {
             //电梯在什么状态下才能关闭
             switch(this.state){
                     case OPENING_STATE:  //可以关门,同时修改电梯状态
                          this.closeWithoutLogic();  
                          this.setState(CLOSING_STATE);
                          break;
                     case CLOSING_STATE:  //电梯是关门状态,则什么都不做
                          //do nothing;
                          break;
                     case RUNNING_STATE: //正在运行,门本来就是关闭的,也什么都不做
                          //do nothing;
                          break;
                     case STOPPING_STATE:  //停止状态,门也是关闭的,什么也不做
                          //do nothing;
                          break;
                     }
     }
     //电梯门开启
     public void open() {
             //电梯在什么状态才能开启
             switch(this.state){
                     case OPENING_STATE: //闭门状态,什么都不做
                          //do nothing;
                          break;
                     case CLOSING_STATE: //闭门状态,则可以开启
                          this.openWithoutLogic();
                          this.setState(OPENING_STATE);
                          break;
                     case RUNNING_STATE: //运行状态,则不能开门,什么都不做
                          //do nothing;
                          break;
                     case STOPPING_STATE: //停止状态,当然要开门了
                          this.openWithoutLogic();
                          this.setState(OPENING_STATE);
                          break;
             }
     }
     //电梯开始运行起来
     public void run() {
             switch(this.state){
                     case OPENING_STATE: //敞门状态,什么都不做
                          //do nothing;
                          break;
                     case CLOSING_STATE: //闭门状态,则可以运行
                          this.runWithoutLogic();
                          this.setState(RUNNING_STATE);
                          break;
                     case RUNNING_STATE: //运行状态,则什么都不做
                          //do nothing;
                          break;
                     case STOPPING_STATE: //停止状态,可以运行
                          this.runWithoutLogic();
                          this.setState(RUNNING_STATE);
                }
     }
     //电梯停止
     public void stop() {
                switch(this.state){
                case OPENING_STATE: //敞门状态,要先停下来的,什么都不做
                     //do nothing;
                     break;
                case CLOSING_STATE: //闭门状态,则当然可以停止了
                     this.stopWithoutLogic();
                     this.setState(CLOSING_STATE);
                     break;
                case RUNNING_STATE: //运行状态,有运行当然那也就有停止了
                     this.stopWithoutLogic();
                     this.setState(CLOSING_STATE);
                     break;
                case STOPPING_STATE: //停止状态,什么都不做
                     //do nothing;
                     break;
             }
     }
     //纯粹的电梯关门,不考虑实际的逻辑
    private void closeWithoutLogic(){
             System.out.println("电梯门关闭...");
     }
     //纯粹的电梯开门,不考虑任何条件
     private void openWithoutLogic(){
             System.out.println("电梯门开启...");
     }
     //纯粹的运行,不考虑其他条件
     private void runWithoutLogic(){
             System.out.println("电梯上下运行起来...");
     }
     //单纯的停止,不考虑其他条件
     private void stopWithoutLogic(){
             System.out.println("电梯停止了...");
     }
}

程序有点长,但是还是很简单的,就是在每一个接口定义的方法中使用switch...case来判断它是否符合业务逻辑,然后运行指定的动作。我们重新编写一个场景类来描述一下该环境,如代码清单6所示。

public class Client {
     public static void main(String[] args) {
             ILift lift = new Lift();
             //电梯的初始条件应该是停止状态
             lift.setState(ILift.STOPPING_STATE);
             //首先是电梯门开启,人进去
             lift.open();     
             //然后电梯门关闭
             lift.close();
             //再然后,电梯运行起来,向上或者向下
             lift.run();
             //最后到达目的地,电梯停下来
             lift.stop();
     }
}

在业务调用的方法中增加了电梯状态判断,电梯要不是随时都可以开的,必须满足一定条件才能开门,人才能走进去,我们设置电梯的起始是停止状态,运行结果如下所示:

电梯门开启...
电梯门关闭...
电梯上下运行起来...
电梯停止了...

我们来想一下,这段程序有什么问题。

  • 电梯实现类Lift有点长

长的原因是我们在程序中使用了大量的switch...case这样的判断(if...else也是一样),程序中只要有这样的判断就避免不了加长程序,而且在业务复杂的情况下,程序会更长,这就不是一个很好的习惯了,较长的方法和类无法带来良好的维护性,毕竟,程序首先是给人阅读的,然后才是机器执行。

  • 扩展性非常差劲

大家来想想,电梯还有两个状态没有加,是什么?通电状态和断电状态,你要是在程序增加这两个方法,你看看Open()、Close()、Run()、Stop()这4个方法都要增加判断条件,也就是说switch判断体中还要增加case项,这与开闭原则相违背。

  • 非常规状态无法实现

我们来思考我们的业务,电梯在门敞开状态下就不能上下运行了吗?电梯有没有发生过只有运行没有停止状态呢(从40层直接坠到1层嘛)?电梯故障嘛,还有电梯在检修的时候,可以在stop状态下不开门,这也是正常的业务需求呀,你想想看,如果加上这些判断条件,上面的程序有多少需要修改?虽然这些都是电梯的业务逻辑,但是一个类有且仅有一个原因引起类的变化,单一职责原则,看看我们的类,业务任务上一个小小的增加或改动都使得我们这个电梯类产生了修改,这在项目开发上是有很大风险的。

既然我们已经发现程序中有以上问题,我们怎么来修改呢?刚刚我们是从电梯的方法以及这些方法执行的条件去分析,现在我们换个角度来看问题。我们来想,电梯在具有这些状态的时候能够做什么事情,也就是说在电梯处于某个具体状态时,我们来思考这个状态是由什么动作触发而产生的,以及在这个状态下电梯还能做什么事情。例如,电梯在停止状态时,我们来思考两个问题:

  • 停止状态是怎么来的,那当然是由于电梯执行了stop方法而来的。
  • 在停止状态下,电梯还能做什么动作?继续运行?开门?当然都可以了。

我们再来分析其他3个状态,也都是一样的结果,我们只要实现电梯在一个状态下的两个任务模型就可以了:这个状态是如何产生的,以及在这个状态下还能做什么其他动作(也就是这个状态怎么过渡到其他状态),既然我们以状态为参考模型,那我们就先定义电梯的状态接口,类图如图4所示。

在类图中,定义了一个LiftState抽象类,声明了一个受保护的类型Context变量,这个是串联各个状态的封装类。封装的目的很明显,就是电梯对象内部状态的变化不被调用类知晓,也就是迪米特法则了(我的类内部情节你知道得越少越好),并且还定义了4个具体的实现类,承担的是状态的产生以及状态间的转换过渡,我们先来看LiftState代码,如代码清单7所示。

public abstract class LiftState{
     //定义一个环境角色,也就是封装状态的变化引起的功能变化
     protected Context context;
     public void setContext(Context _context){
             this.context = _context;
     }
     //首先电梯门开启动作
     public abstract void open();
     //电梯门有开启,那当然也就有关闭了
     public abstract void close();
     //电梯要能上能下,运行起来
     public abstract void run();
     //电梯还要能停下来
     public abstract void stop();
}

抽象类比较简单,我们先看一个具体的实现——敞门状态的实现类,如代码清单8所示。

public class OpenningState extends LiftState {
     //开启当然可以关闭了,我就想测试一下电梯门开关功能
     @Override
     public void close() {
             //状态修改
             super.context.setLiftState(Context.closeingState);
             //动作委托为CloseState来执行
             super.context.getLiftState().close();
     }
     //打开电梯门
     @Override
     public void open() {
             System.out.println("电梯门开启...");
     }
     //门开着时电梯就运行跑,这电梯,吓死你!
     @Override
     public void run() {
             //do nothing;
    }
     //开门还不停止?
     public void stop() {
             //do nothing;
     }
}

我来解释一下这个类的几个方法,Openning状态是由open()方法产生的,因此,在这个方法中有一个具体的业务逻辑,我们是用print来代替了。在Openning状态下,电梯能过渡到其他什么状态呢?按照现在的定义的是只能过渡到Closing状态,因此我们在Close()中定义了状态变更,同时把Close这个动作也委托了给CloseState类下的Close方法执行,这个可能不好理解,我们再看看Context类可能好理解一点,如代码清单9所示。

public class Context {
     //定义出所有的电梯状态
     public final static OpenningState openningState = new OpenningState();
     public final static ClosingState closeingState = new ClosingState();
     public final static RunningState runningState = new RunningState();
     public final static StoppingState stoppingState = new StoppingState();
     //定义一个当前电梯状态
     private LiftState liftState;
     public LiftState getLiftState() {
             return liftState;
     }
     public void setLiftState(LiftState liftState) {
             this.liftState = liftState;
             //把当前的环境通知到各个实现类中
             this.liftState.setContext(this);
     }
     public void open(){
             this.liftState.open();
     }
     public void close(){
             this.liftState.close();
     }
     public void run(){
             this.liftState.run();
     }
     public void stop(){
             this.liftState.stop();
     }
}

结合以上3个类,我们可以这样理解:Context是一个环境角色,它的作用是串联各个状态的过渡,在LiftSate抽象类中我们定义并把这个环境角色聚合进来,并传递到子类,也就是4个具体的实现类中自己根据环境来决定如何进行状态的过渡。关闭状态如代码清单10所示。

public class ClosingState extends LiftState {
     //电梯门关闭,这是关闭状态要实现的动作
     @Override
     public void close() {
             System.out.println("电梯门关闭...");
     }
     //电梯门关了再打开
     @Override
     public void open() {
             super.context.setLiftState(Context.openningState);  //置为敞门状态
             super.context.getLiftState().open();
     }
     //电梯门关了就运行,这是再正常不过了
     @Override
     public void run() {
             super.context.setLiftState(Context.runningState); //设置为运行状态
             super.context.getLiftState().run();
     }
     //电梯门关着,我就不按楼层
     @Override
     public void stop() {
             super.context.setLiftState(Context.stoppingState);  //设置为停止状态
             super.context.getLiftState().stop();
     }
}

运行状态如代码清单11所示:

public class RunningState extends LiftState {
     //电梯门关闭?这是肯定的
     @Override
     public void close() {
             //do nothing
     }
     //运行的时候开电梯门?你疯了!电梯不会给你开的
     @Override
     public void open() {
             //do nothing
     }
     //这是在运行状态下要实现的方法
     @Override
     public void run() {
             System.out.println("电梯上下运行...");
     }
     //这绝对是合理的,只运行不停止还有谁敢坐这个电梯?!估计只有上帝了
     @Override
     public void stop() {
             super.context.setLiftState(Context.stoppingState);//环境设置为停止状态
             super.context.getLiftState().stop();
     }
}

停止状态如代码清单12所示。

public class StoppingState extends LiftState {
     //停止状态关门?电梯门本来就是关着的!
     @Override
     public void close() {
             //do nothing;
     }
     //停止状态,开门,那是要的!
     @Override
     public void open() {
             super.context.setLiftState(Context.openningState);
             super.context.getLiftState().open();
     }
     //停止状态再运行起来,正常得很
     @Override
     public void run() {
             super.context.setLiftState(Context.runningState);
             super.context.getLiftState().run();
     }
     //停止状态是怎么发生的呢?当然是停止方法执行了
     @Override
     public void stop() {
             System.out.println("电梯停止了...");
     }
}

业务逻辑都已经实现了,我们看看怎么来模拟场景类,如代码清单13所示。

public class Client {
     public static void main(String[] args) {
             Context context = new Context();
             context.setLiftState(new ClosingState());
             context.open();
             context.close();
             context.run();
             context.stop();
     }
}

Client场景类太简单了,只要定义一个电梯的初始状态,然后调用相关的方法,就完成了,完全不用考虑状态的变更,运行结果完全相同,不再赘述。

我们再来回顾一下我们刚刚批判的上一段代码。首先是代码太长,这个问题已经解决了,通过各个子类来实现,每个子类的代码都很短,而且也取消了switch...case条件的判断。其次是不符合开闭原则,那如果在我们这个例子中要增加两个状态应该怎么做呢?增加两个子类,一个是通电状态,另一个是断电状态,同时修改其他实现类的相应方法,因为状态要过渡,那当然要修改原有的类,只是在原有类中的方法上增加,而不去做修改。再次是不符合迪米特法则,我们现在的各个状态是单独的类,只有与这个状态有关的因素修改了,这个类才修改,符合迪米特法则,非常完美!这就是状态模式。

状态模式的定义

上面的例子中多次提到状态,本节讲的就是状态模式,什么是状态模式呢?其定义如下:

Allow an object to alter its behavior when its internal state changes.The object will appear to change its class.(当一个对象内在状态改变时允许其改变行为,这个对象看起来像改变了其类。)

状态模式的核心是封装,状态的变更引起了行为的变更,从外部看起来就好像这个对象对应的类发生了改变一样。状态模式的通用类图如图5所示。

我们先来看看状态模式中的3个角色。

  • State——抽象状态角色

接口或抽象类,负责对象状态定义,并且封装环境角色以实现状态切换。

  • ConcreteState——具体状态角色

每一个具体状态必须完成两个职责:本状态的行为管理以及趋向状态处理,通俗地说,就是本状态下要做的事情,以及本状态如何过渡到其他状态。

  • Context——环境角色

定义客户端需要的接口,并且负责具体状态的切换。

状态模式相对来说比较复杂,它提供了一种对物质运动的另一个观察视角,通过状态变更促使行为的变化,就类似水的状态变更一样,一碗水的初始状态是液态,通过加热转变为气态,状态的改变同时也引起体积的扩大,然后就产生了一个新的行为:鸣笛或顶起壶盖,瓦特就是这么发明蒸汽机的。我们再来看看状态模式的通用源代码,首先来看抽象环境角色,如代码清单14所示。

public abstract class State {
     //定义一个环境角色,提供子类访问
     protected Context context;
     //设置环境角色
     public void setContext(Context _context){
             this.context = _context;
     }
     //行为1
     public abstract void handle1();
     //行为2
     public abstract void handle2();
}

抽象环境中声明一个环境角色,提供各个状态类自行访问,并且提供所有状态的抽象行为,由各个实现类实现。具体环境角色如代码清单15所示。

public class ConcreteState1 extends State {
     @Override
     public void handle1() {
             //本状态下必须处理的逻辑
     }
     @Override
     public void handle2() {
        //设置当前状态为stat2
             super.context.setCurrentState(Context.STATE2);
             //过渡到state2状态,由Context实现
             super.context.handle2();
     }
}
public class ConcreteState2 extends State {
     @Override
     public void handle1() {          
             //设置当前状态为state1
             super.context.setCurrentState(Context.STATE1);
             //过渡到state1状态,由Context实现
             super.context.handle1();
     }
     @Override
     public void handle2() {
             //本状态下必须处理的逻辑
     }
}

具体环境角色有两个职责:处理本状态必须完成的任务,决定是否可以过渡到其他状态。我们再来看环境角色,如代码清单16所示。

public class Context {
     //定义状态
     public final static State STATE1 = new ConcreteState1();
     public final static State STATE2 = new ConcreteState2();
     //当前状态
     private State CurrentState;
     //获得当前状态
     public State getCurrentState() {
             return CurrentState;
     }
     //设置当前状态
     public void setCurrentState(State currentState) {
             this.CurrentState = currentState;
             //切换状态
             this.CurrentState.setContext(this);
     }
     //行为委托
    public void handle1(){
             this.CurrentState.handle1();
     }
     public void handle2(){
             this.CurrentState.handle2();
     }
}

环境角色有两个不成文的约束:

  • 把状态对象声明为静态常量,有几个状态对象就声明几个静态常量。
  • 环境角色具有状态抽象角色定义的所有行为,具体执行使用委托方式。

我们再来看场景类如何执行,如代码清单17所示。

public class Client {
     public static void main(String[] args) {
             //定义环境角色
             Context context = new Context();
             //初始化状态
             context.setCurrentState(new ConcreteState1());
             //行为执行
             context.handle1();
             context.handle2();
     }
}

看到没?我们已经隐藏了状态的变化过程,它的切换引起了行为的变化。对外来说,我们只看到行为的发生改变,而不用知道是状态变化引起的。

状态模式的应用

状态模式的优点

  • 结构清晰

避免了过多的switch...case或者if...else语句的使用,避免了程序的复杂性,提高系统的可维护性。

  • 遵循设计原则

很好地体现了开闭原则和单一职责原则,每个状态都是一个子类,你要增加状态就要增加子类,你要修改状态,你只修改一个子类就可以了。

  • 封装性非常好

这也是状态模式的基本要求,状态变换放置到类的内部来实现,外部的调用不用知道类内部如何实现状态和行为的变换。

状态模式的缺点

状态模式既然有优点,那当然有缺点了。但只有一个缺点,子类会太多,也就是类膨胀。如果一个事物有很多个状态也不稀奇,如果完全使用状态模式就会有太多的子类,不好管理,这个需要大家在项目中自己衡量。其实有很多方式可以解决这个状态问题,如在数据库中建立一个状态表,然后根据状态执行相应的操作,这个也不复杂,看大家的习惯和嗜好了。

状态模式的使用场景

  • 行为随状态改变而改变的场景

这也是状态模式的根本出发点,例如权限设计,人员的状态不同即使执行相同的行为结果也会不同,在这种情况下需要考虑使用状态模式。

  • 条件、分支判断语句的替代者

在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰,逻辑混乱,使用状态模式可以很好地避免这一问题,它通过扩展子类实现了条件的判断处理。

状态模式的注意事项

状态模式适用于当某个对象在它的状态发生改变时,它的行为也随着发生比较大的变化,也就是说在行为受状态约束的情况下可以使用状态模式,而且使用时对象的状态最好不要超过5个。

最佳实践

上面的例子可能比较复杂,请各位看官耐心看,看完肯定有所收获。我翻遍了所有能找得到的资料(关于这个电梯的例子也是由《Design Pattern for Dummies》这本书激发出来的),基本上没有一本把这个状态模式讲透彻的(当然,还是有几本讲得不错),我不敢说我就讲得透彻,大家都只讲了一个状态到另一个状态的过渡。状态间的过渡是固定的,举个简单的例子,如图6所示。

这个状态图是很多书上都有的,状态A只能切换到状态B,状态B再切换到状态C。举例最多的就是TCP监听的例子。TCP有3个状态:等待状态、连接状态、断开状态,然后这3个状态按照顺序循环切换。按照这个状态变更来讲解状态模式,我认为是不太合适的,为什么呢?你在项目中很少看到一个状态只能过渡到另一个状态情形,项目中遇到的大多数情况都是一个状态可以转换为几种状态,如图7所示。

状态B既可以切换到状态C,又可以切换到状态D,而状态D也可以切换到状态A或状态B,这在项目分析过程中有一个状态图可以完整地展示这种蜘蛛网结构,例如,一些收费网站的用户就有很多状态,如普通用户、普通会员、VIP会员、白金级用户等,这个状态的变更你不允许跳跃?!这不可能,所以我在例子中就举了一个比较复杂的应用,基本上可以实现状态间自由切换,这才是最经常用到的状态模式。

再提一个问题,状态间的自由切换,那会有很多种呀,你要挨个去牢记一遍吗?比如上面那个电梯的例子,我要一个正常的电梯运行逻辑,规则是开门->关门->运行->停止;还要一个紧急状态(如火灾)下的运行逻辑,关门->停止,紧急状态时,电梯当然不能用了;再要一个维修状态下的运行逻辑,这个状态任何情况都可以,开着门电梯运行?可以!门来回开关?可以!永久停止不动?可以!那这怎么实现呢?需要我们把已经有的几种状态按照一定的顺序再重新组装一下,那这个是什么模式?什么模式?大声点!建造者模式!对,建造模式+状态模式会起到非常好的封装作用。

更进一步,应该有部分读者做过工作流开发,如果不是土制框架,那么就应该有个状态机管理(即使是土制框架也应该有),如一个Activity(节点)有初始化状态(Initialized State)、挂起状态(Suspended State)、完成状态(Completed State)等,流程实例也有这么多状态,那这些状态怎么管理呢?通过状态机(State Machine)来管理,那状态机是个什么东西呢?就是我们上面提到的Context类的升级变态BOSS!

参考文档