1700473310
lift.close（）；
1700473311
1700473312
//再然后，电梯运行起来，向上或者向下
1700473313
1700473314
lift.run（）；
1700473315
1700473316
//最后到达目的地，电梯停下来
1700473317
1700473318
lift.stop（）；
1700473319
1700473320
}
1700473321
1700473322
}
1700473323
1700473324
在业务调用的方法中增加了电梯状态判断，电梯要不是随时都可以开的，必须满足一定条件才能开门，人才能走进去，我们设置电梯的起始是停止状态，运行结果如下所示：
1700473325
1700473326
电梯门开启……
1700473327
1700473328
电梯门关闭……
1700473329
1700473330
电梯上下运行起来……
1700473331
1700473332
电梯停止了……
1700473333
1700473334
我们来想一下，这段程序有什么问题。
1700473335
1700473336
❑电梯实现类Lift有点长
1700473337
1700473338
长的原因是我们在程序中使用了大量的switch……case这样的判断（if……else也是一样），程序中只要有这样的判断就避免不了加长程序，而且在业务复杂的情况下，程序会更长，这就不是一个很好的习惯了，较长的方法和类无法带来良好的维护性，毕竟，程序首先是给人阅读的，然后才是机器执行。
1700473339
1700473340
❑扩展性非常差劲
1700473341
1700473342
大家来想想，电梯还有两个状态没有加，是什么？通电状态和断电状态，你要是在程序增加这两个方法，你看看Open（）、Close（）、Run（）、Stop（）这4个方法都要增加判断条件，也就是说switch判断体中还要增加case项，这与开闭原则相违背。
1700473343
1700473344
❑非常规状态无法实现
1700473345
1700473346
我们来思考我们的业务，电梯在门敞开状态下就不能上下运行了吗？电梯有没有发生过只有运行没有停止状态呢（从40层直接坠到1层嘛）？电梯故障嘛，还有电梯在检修的时候，可以在stop状态下不开门，这也是正常的业务需求呀，你想想看，如果加上这些判断条件，上面的程序有多少需要修改？虽然这些都是电梯的业务逻辑，但是一个类有且仅有一个原因引起类的变化，单一职责原则，看看我们的类，业务任务上一个小小的增加或改动都使得我们这个电梯类产生了修改，这在项目开发上是有很大风险的。
1700473347
1700473348
既然我们已经发现程序中有以上问题，我们怎么来修改呢？刚刚我们是从电梯的方法以及这些方法执行的条件去分析，现在我们换个角度来看问题。我们来想，电梯在具有这些状态的时候能够做什么事情，也就是说在电梯处于某个具体状态时，我们来思考这个状态是由什么动作触发而产生的，以及在这个状态下电梯还能做什么事情。例如，电梯在停止状态时，我们来思考两个问题：
1700473349
1700473350
❑停止状态是怎么来的，那当然是由于电梯执行了stop方法而来的。
1700473351
1700473352
❑在停止状态下，电梯还能做什么动作？继续运行？开门？当然都可以了。
1700473353
1700473354
我们再来分析其他3个状态，也都是一样的结果，我们只要实现电梯在一个状态下的两个任务模型就可以了：这个状态是如何产生的，以及在这个状态下还能做什么其他动作（也就是这个状态怎么过渡到其他状态），既然我们以状态为参考模型，那我们就先定义电梯的状态接口，类图如图26-4所示。
1700473355
1700473356
1700473357
1700473358
1700473359
图26-4 以状态作为导向的类图