【附加题】由结对编程想到的——关于电梯调度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使用。但这样做不是十分优雅。

你可能感兴趣的:(interface)