面向对象设计一一再谈电梯类的实现

上一篇文章讨论如何设计类的使用场景，进而归纳出电梯类的对外接口。今天我们就继续谈谈如何设计电梯类的内部状态、方法以及某些实现。

‌‌‌‌

‌

‌‌

现在我们切换视角，从电梯的使用者，转换到电梯本身。

对于一个电梯，需要知道什么要的信息才能「正确的、有效率的」实现对外方法？举个例子，openDoor方法的具体实现：电梯可以贸然开门么？肯定有很多限制，比如，电梯不能处在运动状态，这个楼层需要在目的楼层、等待楼层的范围内等等。只有掌握了这些电梯内部的信息，电梯对外的方法才能正确的被实现。

那让我们来考虑一下电梯内部的状态有哪些？（思考一下这些状态和外部方法实现的关联）

a. 最大楼层，最低楼层；

b. 运动状态：Idle, Moving, Loading, etc;

c. 当前所在楼层，当前电梯运动方向(up/down)

d. 目的楼层集合；

因此我们简单写一下类的构造函数。

‌‌‌‌‌

下面看对外方法的具体实现，注意分析电梯内部状态和对外行为之间的联系。

openDoor()方法对于电梯楼层相关的状态没有影响，但是修改了电梯的运动状态。另外一方面，开电梯门是一个机械操作，因此我们可以在Elevator类中使用controller的对象，来负责机械操作。

‌

‌‌‌

‌

‌‌‌addDestinationFloor()方法会影响电梯下一步要运行的方向，同时也可能会影响电梯的状态。

‌

‌‌‌

‌

在addDestinationFloor()中，当电梯已经处于Moving状态的时候，elevator的event loop可以正确处理新的请求。如果电梯之前处于Idle状态，那么电梯应该重新启动event loop。对于event loop的实现，一个简单的实现如下：‌

‌‌‌

‌我们没有具体实现hasDestinationFloor()和getNextDestinationFloor()，但是通过电梯内部的currentFloor以及reqFloorList, 这两个方法应该不难实现。

以上是一个简单的电梯类的简单框架实现，它充分的体现了OOP中的重要原则，即封装内部状态，提供对外接口。

作为电梯类的使用者，我们不关心电梯类的内部实现，比如请求的调度算法或者机械功能。使用者关心的是电梯类提供的对外方法接口是否满足使用场景的需求。另一方面，只要能保持电梯类的对外接口不变，它可以自由的修改内部实现。这就是类设计时接口和具体实现的解耦。

OOD完全没有标准答案。我们举出的例子也是为了说明设计类过程中内部状态、方法和对外接口直接的关系。事实上它本身也有很多不足，比如线程不安全（想想如果两个addDestinationFloor同时到达elevator instance会怎样？）；很多使用场景的限制没有实现，比如电梯在某一层停留时间有限制，或者有人直接按关门键缩减电梯等待时间等。但只要设计中能体现出OOD的核心原则，面试就基本过关啦。

在面试OOD的过程中，如果有剩余时间，提出可改进的地方，如果能改进其中的一两项，一定加分。