在电梯系列的作业中，笔者的整体架构几乎没有发生改变。现介绍如下，对于一个电梯系统，主要的工作步骤就是获取乘客请求、分派请求、执行请求。针对这样的工作模式，笔者设计了Elevator、Uselist两个主要的类（获取请求由主类完成）。在线程的配合方面，笔者采用的是消费者-生产者模式，Uselist相当于托盘，不同的是该类还负责向不同的电梯分配请求。
一、作业分析
(一)第一次作业
调度算法：严格采用可稍带原则，中途楼层遇到新的乘客就进行搭载。
UML类图：
复杂度分析：
由于只有一部电梯，因此方法都相对简单，在复杂度方面表现良好。
Bug分析：未出现bug
（二）第二次作业
调度算法：本次作业电梯数变为了多部，并且电梯增加了最大乘客数的限制。在调度方向，笔者采用了贪心策略，电梯每次都优先前往最近的有乘客的楼层，并优先去往距离当前楼层最近的楼层，在过程中仍然可稍带。从最后的结果来看，在不考虑单个乘客的等待时间的情况下，这种算法的效率很不错，达到了由及局部最优取得整体最优的效果。
UML类图
复杂度分析
在复杂度方面，本次作业的表现也较好。
Bug分析：未出现bug
(三）第三次作业
调度算法：本次作业电梯出现了不同的种类，并且不同的电梯可前往的楼层是不同的，这意味着需要换乘，除此，电梯的数量也会动态增加。笔者认为电梯数量的增加不是主要的问题，因此将作业的重点放到了换乘策略上。经过对楼层的分析，发现1层和15层是三种电梯都会到达的楼层，因此1层和15层就作为换乘的中转站。笔者采用的策略是当一个乘客进入电梯后，如果不需要换乘就前往相应楼层，如果需要换乘就根据乘客的目的楼层去往1层或者15层。这种调度方式的效率并不高，但是可以保证正确性。由于笔者能力有限，就没有做过多的优化。
UML类图
复杂度分析
可以看出部分方法被标红，被标红的方法主要的功能就是对乘客请求的调度，出现了很多对请求队列的遍历，在这方面笔者认为有很大的优化余地。但是值得注意的是，电梯的run方法也被标红，主要的原因是电梯线程在运行过程中需要大量的与请求队列进行读写操作，但是笔者还未想到如何降低电梯与请求队列之间的耦合度，这也是需要改进的一个方面。
Bug分析：在本次作业中笔者出现了重大的错误。C类电梯不能前往15层以上，而笔者错误的将C类电梯的可达楼层设置为了所有的奇数楼层。由于这个bug，在强测中只得到了35分，互测中也有被hack。但是bug修复中只修改了2行代码就完全修复了。出现了这样的错误笔者心情十分复杂，只能在之后多注意各种约束条件。
可扩展性：Uselist进行请求队列的管理，Elevator负责电梯的运行。比较符合SRP原则。但是对OCP、LSP、ISP、DIP几个原则上表现就不是很好。笔者分析后认为，对笔者来说第三次作业算是比较复杂的，在复杂程序的设计中，会出现思路不清晰，最后导致思绪复杂，使得原来各司其职的类混杂了多余的功能。在对类之间的协作上笔者还需要加强。
二、HACK策略
首先查看是否出现了轮询的情况。没有的话，就主要集中在特殊情况，比如：同一时间出现大量乘客（请求相同或者请求各不相同）、换乘的情况。
三、心得体会
在电梯系列的作业中，线程安全是一个重要的问题。笔者是第一次接触多线程相关的程序，因此在第一次作业中，感觉到很困难。但是经过了第一次作业之后，对于多线程的理解上，感觉就通透了很多。笔者比较满意的是，第一次作业设置的整体架构比较稳定，在之后的迭代中程序的整体架构没有发生大的变化，这给功能的迭代带来了极大的方便。这一点是笔者认为比求导系列作业有很大进步的地方。但是，在第三次作业中也出现了比较大的失误，对C类电梯的限制条件设置错误，导致了bug的产生，这是完全不应该的，希望能引以为戒。在作业的过程中，笔者也体会到了设计模式的精妙之处，采取适当的设计模式确实可以减轻设计的负担，因此笔者也认为要多多了解不同的设计模式，这对程序的设计是很有帮助的。
