感谢刘晟昊同学在我解决疑难问题过程中的耐心帮助。
本单元共有三次作业，分别为：
HW1：实现单个电梯的运行。
HW2：实现多个同类型的电梯的运行。
HW3：实现多个不同类型、可动态加入的电梯的运行。
一、design strategy
三次作业均使用类生产者消费者模型和指导书中描述的ALS策略，属于迭代开发的过程。
几个关键类：
MyInput：生产者类，负责读入请求、创建电梯、控制线程结束。
Passenger：请求类，负责自行规划调整行程、决定是否进入电梯。
Itinerary：存储乘客的行程信息。
Scheduler：共享资源类，负责分配乘客、驱动电梯、监视电梯的工作情况。其中包括维护重要参数workingCount，即空转电梯的个数。
Elevator：生产者+消费者类，负责运行停靠、乘客的放出接入。
电梯是如何完成工作的?
电梯被创建后，Scheduler.pickForEmptyElevator为其确立首个目的地，开始运行。
运行期间，对于每一个可停留楼层，Scheduler.pick（有无到达乘客）与Elevator.hasArrival（有无可接入乘客）决定是否停留，停留后依次放出、接入乘客。当电梯为空，再次调用Scheduler.pickForEmptyElevator。
输入结束时，MyInput通知Scheduler进行关闭，后者首先将自己的工作状态布尔值isWorking设置为false，并持续维护等待队列与代表电梯工作状态的参数workingCount。在得知Scheduler已关闭、等待队列为空、所有电梯均空转时，电梯自行关闭。
二、code analysis
先回顾一下三次作业的UML类图和Complexity metrics。
HW1
HW2
HW3
HW1
| class | OCavg | WMC |
|---|---|---|
| Elevator | 1.69 | 22 |
| MainClass | 1.00 | 1 |
| MyInput | 2.00 | 4 |
| Passenger | 1.33 | 8 |
| Scheduler | 2.00 | 14 |
| Total | 49 | |
| Average | 1.69 | 9.80 |
HW2
| class | OCavg | WMC |
|---|---|---|
| Elevator | 1.85 | 24 |
| MainClass | 1.00 | 1 |
| MyInput | 2.50 | 5 |
| Passenger | 1.29 | 9 |
| Scheduler | 2.00 | 12 |
| Total | 51 | |
| Average | 1.76 | 10.20 |
HW3
| class | OCavg | WMC |
|---|---|---|
| Elevator | 1.94 | (color{red}{31}) |
| ElevatorSpecification | 1.00 | 5 |
| Itinerary | 1.00 | 4 |
| MainClass | 1.00 | 1 |
| Passenger | 1.92 | 23 |
| SafeOutput | 1.00 | 1 |
| Scheduler | 2.17 | 13 |
| Total | 83 | |
| Average | 1.77 | 10.38 |
可以看到，三次作业下来，代码的耦合度不高不低。由于一直坚持使用较为简单的调度方式以及在第一次作业的设计中对功能的分配较为合理，电梯类和调度器类的复杂度并没有失控，各个类方法各司其职，没有出现个别方法职能过多的情况。唯一不同的是乘客类在HW3中加入了寻路算法DFS，导致复杂度明显上升。
三、 bug analysis
HW1：电梯开门时提取arriveTime过早，导致停留不足400ms。
HW2：电梯满员时调度器仍然向其分配乘客。
HW3：在强测和互测中没有发现bug。
这些只需要改动一两行即可修复的低级错误在评测中造成了很大的分数损失，但是三次作业并没有出现线程安全问题，因此本单元还是学有所得。
四、hack strategy
1.理解程序。
2.按照程序实现流程定位各部分的核心代码。
3.手动构造数据测试各部分边界情况，发现bug时尝试修复，再重复进行步骤3直到完成所有部分。
五、对HW3可扩展性的思考
HW3的调度方式沿用了前两次作业的弱化版ALS，优先考虑电梯的运行方向，在乘客的行程安排上也只考虑了各类型电梯的可停靠楼层，没有考虑电梯的距离远近和搭载状况，因此电梯的乘客接送效率很低。如果能把电梯与乘客的距离作为调度的另一决定条件，电梯的性能将有所提高。因此，可以适当增加电梯和其他类的通信频率，及时对电梯的位置、载客状况进行通知。
六、心得体会
善用一些设计模式才能够为程序带来层次感和组织感，实现易维护、易扩展、易复用、灵活性好的特点。
坚持SOLID原则是实现良好迭代开发的不二法门。本单元的三次作业并没有使用接口、继承的必要，在这样的情况下，我认为只需坚持一点：精细分工。
从下一单元起，希望自己能够从更贴近问题本质的角度设计结构；不仅仅追求正确，要大胆尝试不同的设计思路，把学会更好地设计程序作为学习本课程的真正目标。