一、设计策略
第一次作业：一部目的选层电梯，1-15层。
策略就是输入一个producer线程，传送带是elevatorMap类，consumer线程是电梯。producer线程持续获取请求放入传送带，供consumer按需索取。consumer线程采用捎带策略，在自己送往目的地的途中如果路过有乘客要上电梯就带上。目的地的选择是：如果电梯里没人就选等待队列里来的最早的人的出发楼层作为目的地，如果电梯里有人就选择电梯里来的最早的人的目的楼层，每次送达目的地后再获得下一个目的地。如果目的地比目前楼层大就上行，小就下行。如果等于的话进入上下乘客环节。移动后如果有上下电梯的乘客就让他们上下电梯，没有就继续走。下电梯就是从电梯里remove，上电梯就是从请求队列里remove掉，加入电梯里。
第二次作业：1-5部电梯，每部准乘7人，-3-16层。
第二次作业没什么变化，初始时改为根据指令创建1-5个consumer线程。此外，要在上下电梯的时候限制一下人数，如果即将超载就禁止进入。然后再扩展一下楼层。
第三次作业：分三种类型的电梯，每种有不同的可停靠楼层和载客数以及运行速度，并且可以新增电梯。
扩展电梯类，增加变量电梯类型，电梯荷载人数，运行速度。根据每类电梯的特性，要在特定的楼层略过继续上行或下行。关于换乘，我的初步策略是能不换乘就不换乘，然后需要换乘统一到一层换乘。换乘时将出电梯的人改变出发楼层后重新加入到请求队列中。但是这样太慢了，走了很多冤枉路。因此对于每一个需要换乘的乘客，要找到他换乘的最佳位置。找到后就可以明确他的换乘地点和换乘电梯类型了。
二、扩展性分析
SRP——单一职责原则
这一点上我的设计存在不足。电梯的上下乘客操作放到了elevatorMap（请求队列）这个类里边，然后电梯类里包含了电梯这个对象的特征和方法以及调度策略。应将职责进行分离。
OCP——开闭原则
这一点做的也不理想，“开”的不够。没能够对于扩展有足够的开放性。
LSP——里氏替换原则、ISP——接口隔离原则
因为没有采用继承关系和接口，因此没有体现。
DIP——依赖倒置原则
从上层架构开始写，最后再完善每个模块的内容，实现了高层模块不应该依赖于底层模块,二者都应该依赖于抽象的原则。
三、程序结构分析
uml类图
度量分析
sequence diagram
四、bug分析
在如何结束线程上花费了一些时间，改来改去还是bug，rtle。多次尝试后终于解决。然后第三次作业有一处疏忽忘改了荷载人数导致出现bug。
五、hack
对于如何hack，本人也很头疼。对于没有评测机的我，只能用脑子去构造数据，属实很惨。hack时都是先试试我遇到困难的点有没有人疏忽，然后还是从调度策略入手去了解他的策略，在着手构造测试集。
六、总体感受
多线程很棒，挑战与收获并存。第一次接触多线程，体会了进步高效利用计算机的计算资源的方法，关于多线程还有很多知识等待我去发掘。