OO第二单元总结
设计策略分析
本单元作业相较第一单元来说本身的功能要求就更具有面向对象性，故我在三次作业的迭代中没发生大的改动。
总的思路是模拟器不断将请求推送到调度器的请求队列，电梯不断从该队列 获得请求，存放到自己内部的请求队列中，然后自己内部调度执行。
第三次作业的时序图如下，实际上三次作业思路相似。
main函数会先创造Dispatch类，这个类作用相对简单，用于接收并存储请求，同时等待电梯来取走请求，并提供一些查询方法。
main函数随后创造Elevator类，这些电梯会扫描Dispatch中的请求并根据调度策略取走请求。故我的调度策略实际上是在电梯内部实现的。
架构设计的可扩展性
我在Elevator类中实现了上行到目标楼层和下行到目标楼层的方法，因此修改调度策略较为方便。同时作业中要求的人数限制等只需修改Dispatch中的上电梯方法即可。
迭代过程中主要通过修改已有代码来适应新的需求，不适应OCP原则，我会在以后的编程中更加注意。
第一次作业分析
可以看到，由于需要在电梯类中实现电梯自身的功能和调度算法，Elevator类较大，其中的方法行数规模也较大，这是我这三次作业的通病，需要改进进一步降低耦合度。
第一次作业出现的BUG是由于调度策略的问题发生了超时现象，修改调度方法即完成BUG修复。
第二次作业分析
可以看到，在修改简化了调度算法后，Elevator类及其方法规模有所减小，但还需要改进进一步降低耦合度。同时由于功能需求的增加，Dispatch类规模扩大了。
第二次作业在公测中表现较好，但在互测中还是被发现了BUG，表现为所有电梯都满载后电梯会卡住。修复方式为在电梯满载后禁止电梯尝试上人。
第三次作业分析
可以看到，由于功能需求不断增加，并且修复上次作业BUG的需要，Elevator和Dispatch类的规模进一步扩大了，需要改进进一步降低耦合度。
这次作业未出现BUG，但是性能分得分较低，考虑是优先运送不需换乘的人员导致需要换乘的人员等待时间过长导致。
终止进程的方法是在输入结束后，检测到Dispatch中队列为空且所有电梯都在WAITING状态即结束。
hack策略
对评测机搭建不熟悉，使用手搓样本导致未发现他人BUG。
需要学习评测机的搭建。
心得体会
本次作业迭代开发相比第一单元较为舒适，可能是由于我的面向对象思维在课堂上得到了强化，也可能是由于本次作业本来就是对象性质较强的作业，不像第一单元采用面向过程编程也能勉强勉强。
意识到将过多的功能交给Elevator类实现会导致代码冗长不好维护，而且耦合度过高，以后编程会更加注意。
本次作业初步接触了java多线程编程，了解了线程安全的知识。