【附加题】由结对编程想到的——关于电梯调度Interface的改进

【附加题】由结对编程想到的——关于电梯调度Interface的改进

关于用户外请求的处理

我们知道，用户对一个电梯的请求分为两种：内请求（Destination Request）与外请求（Direction Request），在Real Scenario中，对同一层的内请求与外请求大多数情况下只会发生一次，比如，有5个人在一层等上行电梯，他们之中只会有一个人（很可能是最先到的那个）按上行请求的按钮，其他人看到按钮亮后，就不会再按了。同样，同一楼层的内请求也很可能只有一次，即使有多个人要到这个楼层。而测试程序认为每个Passenger都要向Scheduler提交请求，这样，Scheduler就能够判断哪一层的请求最多，但在实际情形中，这在很大程度上市不现实的（除非大家都等不急了，狂按电梯按钮…..）

改进意见：测试程序对于乘客的请求进行适当过滤，对于同一层的内请求，同一层同一方向上的外请求，只送达Scheduler一次。

 

对于IElevator.HistoryDirection

这次由于我们Pair一名同学杀G迟迟不归。。导致整体进度拖慢，在大家抓狂般分析程序时，被IElevator的HistoryDirection弄的云里雾里。。本来以为这个是可用可不用的属性，后来，才发现，乘客需要通过访问他来判断电梯今后的走向，以决定是否乘梯，比如，一名乘客在5楼提交下行请求，调度器从1楼派梯，等电梯上行到达5楼开门后，由于HistoryDirection<>Direction.Down，乘客是不会自动进入电梯的。我们认为，HistoryDirection是储存电梯前一个运行状态的属性，应该由IElevator自行维护，而不允许外界修改。同时，针对于上文提到的情形，IElevator可以提供NotifyPassengerDirection()方法，告知乘客电梯运行的方向，方便乘客判断是否乘梯

 

关于敏感信息的隐藏

这一点在我们上一条博文里没有写，在这里补充说明：

IElevator定义了很多方法，一部分是提供给Scheduler的，一部分是提供给Passenger和World的，而后者有很多敏感逻辑，比如StatusUpdateForEveryTick()，由于它也是public的，这样Scheduler也可以访问，存在一定的风险。但由于他们同处一个程序集下，用什么访问修饰符都不好使。可以采用折中方案：将IElevator接口一分为二，一个叫IElevator，供Scheduler食用，一个叫IElevatorManager之类的，包含控制逻辑，供World使用。但这样做不是十分优雅。