26.1 城市的纵向发展功臣——电梯
现在城市发展很快，百万级人口的城市很多，那其中有两个东西的发明在城市的发展中起到非常重要的作用：一个是汽车，另一个是电梯。汽车让城市可以横向扩展，电梯让城市可以纵向延伸，向空中伸展。汽车对城市的发展我们就不说了，电梯，你想想看，如果没有电梯，每天你需要爬15层楼梯，你是不是会累坏了？建筑师设计了一个没有电梯的建筑，投资者肯定不愿意投资，那也是建筑师的耻辱，今天我们就用程序表现一下这个电梯是怎么运作的。
我们每天都在乘电梯，那我们来看看电梯有哪些动作（映射到Java中就是有多少方法）：开门、关门、运行、停止。好，我们就用程序来实现一下电梯的动作，先看类图设计，如图26-1所示。
图26-1 电梯的类图
非常简单的类图，定义一个接口，然后是一个实现类，然后业务场景类Client就可以调用，并运行起来，简单也要实现出来。看看该程序的接口，如代码清单26-1所示。
代码清单26-1 电梯接口
public interface ILift { //首先电梯门开启动作 public void open; //电梯门可以开启，那当然也就有关闭了 public void close; //电梯要能上能下 public void run; //电梯还要能停下来 public void stop;} 接口有了，再来看实现类，如代码清单26-2所示。
代码清单26-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(/"电梯停止了.../"); }} 电梯的开、关、运行、停都实现了，再看看场景类是怎么调用的，如代码清单26-3所示。
代码清单26-3 场景类
public class Client { public static void main(String args) { ILift lift = new Lift; //首先是电梯门开启，人进去 lift.open; //然后电梯门关闭 lift.close; //再然后，电梯运行起来，向上或者向下 lift.run; //最后到达目的地，电梯停下来 lift.stop; }} 运行的结果如下所示：
电梯门开启...
电梯门关闭...
电梯上下运行起来...
电梯停止了...
太简单的程序了！每个程序员都会写这个程序，这么简单的程序还拿出来显摆，是不是太小看我们的智商了？非也，非也，我们继续往下分析，这个程序有什么问题？你想想，电梯门可以打开，但不是随时都可以开，是有前提条件的。你不可能电梯在运行的时候突然开门吧？！电梯也不会出现停止了但是不开门的情况吧？！那要是有也是事故嘛，再仔细想想，电梯的这4个动作的执行都有前置条件，具体点说就是在特定状态下才能做特定事，那我们来分析一下电梯有哪些特定状态。
● 敞门状态
按了电梯上下按钮，电梯门开，这中间大概有10秒的时间，那就是敞门状态。在这个状态下电梯只能做的动作是关门动作。
● 闭门状态
电梯门关闭了，在这个状态下，可以进行的动作是：开门（我不想坐电梯了）、停止（忘记按路层号了）、运行。
● 运行状态
电梯正在跑，上下窜，在这个状态下，电梯只能做的是停止。
● 停止状态
电梯停止不动，在这个状态下，电梯有两个可选动作：继续运行和开门动作。
我们用一张表来表示电梯状态和动作之间的关系，如图26-2所示。
图26-2 电梯状态和动作对应表（○表示不允许，☆表示允许动作）
看到这张表后，我们才发觉，哦，我们的程序做得很不严谨，好，我们来修改一下，如图26-3所示。
在接口中定义了4个常量，分别表示电梯的4个状态：敞门状态、闭门状态、运行状态、停止状态，然后在实现类中电梯的每一次动作发生都要对状态进行判断，判断是否可以执行，也就是动作的执行是否符合业务逻辑，实现类中有4个私有方法是仅仅实现电梯的动作，没有任何前置条件，因此这4个方法是不能为外部类调用的，设置为私有方法。我们先看接口的改变，如代码清单26-4所示。
图26-3 增加了状态的类图
代码清单26-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，设置电梯的状态。我们再来看实现类是如何实现的，如代码清单26-5所示。
代码清单26-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来判断它是否符合业务逻辑，然后运行指定的动作。我们重新编写一个场景类来描述一下该环境，如代码清单26-6所示。
代码清单26-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个状态，也都是一样的结果，我们只要实现电梯在一个状态下的两个任务模型就可以了：这个状态是如何产生的，以及在这个状态下还能做什么其他动作（也就是这个状态怎么过渡到其他状态），既然我们以状态为参考模型，那我们就先定义电梯的状态接口，类图如图26-4所示。
图26-4 以状态作为导向的类图
在类图中，定义了一个LiftState抽象类，声明了一个受保护的类型Context变量，这个是串联各个状态的封装类。封装的目的很明显，就是电梯对象内部状态的变化不被调用类知晓，也就是迪米特法则了（我的类内部情节你知道得越少越好），并且还定义了4个具体的实现类，承担的是状态的产生以及状态间的转换过渡，我们先来看LiftState代码，如代码清单26-7所示。
代码清单26-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;} 抽象类比较简单，我们先看一个具体的实现——敞门状态的实现类，如代码清单26-8所示。
代码清单26-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类可能好理解一点，如代码清单26-9所示。
代码清单26-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个具体的实现类中自己根据环境来决定如何进行状态的过渡。关闭状态如代码清单26-10所示。
代码清单26-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; }} 运行状态如代码清单26-11所示。
代码清单26-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; }} 停止状态如代码清单26-12所示。
代码清单26-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(/"电梯停止了.../"); }} 业务逻辑都已经实现了，我们看看怎么来模拟场景类，如代码清单26-13所示。
代码清单26-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条件的判断。其次是不符合开闭原则，那如果在我们这个例子中要增加两个状态应该怎么做呢？增加两个子类，一个是通电状态，另一个是断电状态，同时修改其他实现类的相应方法，因为状态要过渡，那当然要修改原有的类，只是在原有类中的方法上增加，而不去做修改。再次是不符合迪米特法则，我们现在的各个状态是单独的类，只有与这个状态有关的因素修改了，这个类才修改，符合迪米特法则，非常完美!这就是状态模式。