1700473354
我们再来分析其他3个状态，也都是一样的结果，我们只要实现电梯在一个状态下的两个任务模型就可以了：这个状态是如何产生的，以及在这个状态下还能做什么其他动作（也就是这个状态怎么过渡到其他状态），既然我们以状态为参考模型，那我们就先定义电梯的状态接口，类图如图26-4所示。
1700473355
1700473356
1700473357
1700473358
1700473359
图26-4 以状态作为导向的类图
1700473360
1700473361
在类图中，定义了一个LiftState抽象类，声明了一个受保护的类型Context变量，这个是串联各个状态的封装类。封装的目的很明显，就是电梯对象内部状态的变化不被调用类知晓，也就是迪米特法则了（我的类内部情节你知道得越少越好），并且还定义了4个具体的实现类，承担的是状态的产生以及状态间的转换过渡，我们先来看LiftState代码，如代码清单26-7所示。
1700473362
1700473363
代码清单26-7 抽象电梯状态
1700473364
1700473365
public abstract class LiftState{
1700473366
1700473367
//定义一个环境角色，也就是封装状态的变化引起的功能变化
1700473368
1700473369
protected Context context；
1700473370
1700473371
public void setContext（Context_context）{
1700473372
1700473373
this.context=_context；
1700473374
1700473375
}
1700473376
1700473377
//首先电梯门开启动作
1700473378
1700473379
public abstract void open（）；
1700473380
1700473381
//电梯门有开启，那当然也就有关闭了
1700473382
1700473383
public abstract void close（）；
1700473384
1700473385
//电梯要能上能下，运行起来
1700473386
1700473387
public abstract void run（）；
1700473388
1700473389
//电梯还要能停下来
1700473390
1700473391
public abstract void stop（）；
1700473392
1700473393
}
1700473394
1700473395
抽象类比较简单，我们先看一个具体的实现——敞门状态的实现类，如代码清单26-8所示。
1700473396
1700473397
代码清单26-8 敞门状态
1700473398
1700473399
public class OpenningState extends LiftState{
1700473400
1700473401
//开启当然可以关闭了，我就想测试一下电梯门开关功能
1700473402
1700473403
@Override