本单元的三次作业中，我采用了相似的策略：采用输入线程与电梯线程通过线程安全的调度器进行交互的方式。这种方式基本属于生产者-消费者模式。在调度器的设计方面，我主要采用synchronized关键字结合wait和notify方法完成互斥访问和同步控制。
Elevator类有且仅有一个public方法：run方法，仅仅负责执行电梯的运行逻辑。
Main类有且仅有一个public方法：main方法。但main方法既负责创建线程，又负责输入的处理与结束，具有多重责任。可以采取创建新的输入类和输入线程的方法解决这个设计问题。
Dispatcher类具有多个public方法，但每个方法都有唯一确定的职责，通过下面章节中UML类图即可确认这一特性。Dispatcher类负责将请求放置于每一楼层，供Elevator取用，满足了SRP原则。
FloorConverter类有两个public方法，负责将楼层号与数组下标相互转换，满足了SRP原则。
FloorSelector类有两个public方法，分别用来判断当前层是否可以停靠和选择乘客的目的楼层。这两个职责都需要电梯的停靠信息，而且逻辑联系较为紧密，因此可以置于同一类中完成。
本次作业中除继承Thread类外没有使用任何继承，几乎都是通过修改已有实现完成新增功能，违反了OCP原则。
本次作业中除继承Thread类外没有使用任何继承，因此该原则无从体现。
本次作业中没有使用任何接口，因此该原则无从体现。
本次作业中除继承Thread类外没有使用任何继承，且没有使用任何接口，因此该原则无从体现。
通过上面的分析可以看出，扩展功能几乎一定需要通过改写已有的实现来完成。但由于类的public方法职责都较为明确，这样的设计可以为功能的扩展带来一定的便利。
本次作业构建了三个类。这些类的封装较好，对外暴露的方法较少，且都具有明确的职责。大部分方法具有明确的职责，也较为简洁。但是，Elevator类的run方法展开了电梯的一次运行逻辑，整体较为复杂；Dispatcher类的getTask方法也较为复杂，不便改动和维护。
本次作业与上一次作业架构极为相似，只是多了FloorConverter类。因此优缺点与上次大体相同，在此不再赘述。
本次作业构建了五个类。这些类的封装较好，对外暴露的方法较少，且都具有明确的职责，类间的协作关系也较为明确。大部分方法具有明确的职责，也较为简洁。但是，与前两次作业一样，Elevator类的run方法仍然展开了电梯的一次运行逻辑，整体较为复杂；Dispatcher类的getTask方法也较为复杂，不便改动和维护。
由于三次作业的线程交互模式较为类似，因此统一绘制UML时序图如下。
本单元作业在公测和互测中未出现任何bug。
本次作业同第一单元不同，需要做到在线交互。因此，本次作业的测试要求更高。但是，由于摸鱼心切，我仍然采用了手动构造测试用例的方法。因此，本单元我未能发现他人的任何bug。
通过本单元的三次作业，我对Java多线程编程有了一个初步的认识，并了解了一些简单的互斥访问与同步控制的方法。在多线程编程中，通过线程安全的共享对象来完成线程间交互是十分清晰而简洁的方式。通过对象锁，可以使该对象在同一同步块内只能被一个线程访问，且不会被打断。再结合wait和notifyAll方法，可以避免轮询，高效利用CPU资源。此外，在设计中遵循SOLID原则及一些其他重要的设计原则也是十分重要的，这些原则保证了程序结构的清晰性和良好的可扩展性。在本单元作业中，部分设计原则未能体现甚至有所违背，在今后的编程中会多加注意。