1. 设计策略
调度的策略大多集中到了电梯里，调度器反而只剩下一个队列。
2. 基于度量的分析
类图：
方法复杂度：
如上所说，调度的策略大多集中到了电梯里，导致电梯的run方法复杂度大大提升。
类复杂度：
solid原则：
Single Responsibility Principle (单一功能原则)： 基本满足，电梯、输入处理、调度队列的功能职责都只归属于一个类。
Open Close Principle（开闭原则）: 不满足，扩展性较差，电梯的调度策略都在电梯里，上下楼的方法用的是累计，然后sleep（楼层数 * time），无法动态地检查每一楼层。
Liskov Substitution Principle（里氏替换原则）： 满足。本次作业除 extends Thread 外没有涉及到继承关系。
Interface Segregation Principle（接口隔离原则）： 满足。本次作业没有涉及到接口。
Dependency Inversion Principle（依赖反转原则）： 满足。
3. 程序的Bug分析
第一次作业逻辑比较简单，所以在强测和互测中暂时还没有发现Bug。
4. 互测策略
由于本次作业比较简单，我在互测中同学的代码中没有发现线程安全相关的问题。在互测中主要靠读别人的代码，发现一些细节上的、功能相关的问题，比如顶层和底层的限制等。
第二次作业
1. 设计策略
第二次作业的要求是在第一次作业的基础上添加了地下三层和ALS可调度策略，要求我们不再一次只载一个人，而是做得更像我们生活中的电梯，更真实效率更高的电梯。
我的架构大部分沿用了前一次作业的设计，仍旧是四个类，三个线程--主线程、输入线程和电梯线程。其中输入线程和电梯线程共享一个对象--调度器队列。
其中调度器仍然只充当一个队列的角色，只负责存取乘客的信息，大部分的调度的策略都被我写在电梯类里。
而电梯的调度算法没有使用指导书推荐的算法，而是使用了一个电梯的经典算法--Scan算法。
2. 基于度量的分析
类图：
方法复杂度：
其中 Elevator.need() 是检查 ”是否还有继续在这个方向上运行的必要“，检查后若没有必要则掉头。
这两个方法耦合度较高。
类复杂度：
电梯类承载了太多调度的策略，导致复杂度较高。
solid原则：
Single Responsibility Principle (单一功能原则)： 不满足。电梯类不仅承担了电梯运行的指责，还承担了调度的指责。
Open Close Principle（开闭原则）: 不满足，扩展性仍然较差。电梯的调度策略都在电梯里，无法拓展到多电梯。
Liskov Substitution Principle（里氏替换原则）： 满足。本次作业除 extends Thread 外没有涉及到继承关系。
Interface Segregation Principle（接口隔离原则）： 满足。本次作业没有涉及到接口。
Dependency Inversion Principle（依赖反转原则）： 基本满足。
3. 程序的Bug分析
本次作业中我的程序里没有发现功能上的Bug，但存在性能上的Bug导致实际运行时间过长。
我的调度策略是，在电梯为空时接第一个人，然后以第一个人的方向开始运行。这种调度方式会导致接完第一个人后，去接的那个方向上的以后的人都会被忽略。
如图样例，当第一个请求出现，电梯会先去接第一个遇到的请求，接了之后立马会把方向转化为他想去的方向，即接到第一个八楼的人会立马往下运行，而九楼及以上的人都接不上。如上的样例需要来回送九趟……
4. 互测策略
与上一次作业差不多，主要检查一些功能上的细节，捎带的功能检查等。
在讨论区看到了一个大佬的自动测试，替换掉官方的输入输出接口可以直接在输入中加入时间，实现自动定时输入。
第三次作业
1. 设计策略
第三次作业的难度对于前两次作业总是一个飞跃，增加了两部电梯，每部电梯的可停靠楼层、运行一层的时间和最大载客量都不同。三部电梯之间的差异就决定了这一次我只能重构。
这一次作业我的程序有五个线程，主线程、输入线程和三个电梯线程。三个电梯线程和输入线程共享一个调度器对象，输入线程负责将请求放进调度器，然后调度器根据请求的起始楼层，结合三部电梯的运行状态，将请求拆分或者直接放入某部电梯的等待队列。
而在拆分请求的执行先后顺序控制上，我建立了三个个数组，分别保存了三部电梯等待人员ID和是否经过拆分，若经过拆分则不能接，然后每次送达都检查一次这个数组，更新数组。
2. 基于度量的分析
类图：
整体构造和上次一样。
方法复杂度：
方法复杂度显示出 Elevator.need() （检查是否有必要继续向现在的方向运行）和 Elevator.run() 耦合度较高，判定结构过于复杂。同时 RequestManager.addRequest(PersonRequest) 方法（尝试拆分请求并分发到电梯的等待队列）复杂度过高。
类复杂度：
由图可知，Elevator 类和 RequestManager 类之间耦合过高。
solid原则：
Single Responsibility Principle (单一功能原则)： 勉强满足。电梯、调度器、输入都只承担了自己应该承担的职责，但电梯、调度器的职责还是太过复杂。
Open Close Principle（开闭原则）: 满足，具有扩展性。
Liskov Substitution Principle（里氏替换原则）： 满足。本次作业除 extends Thread 外没有涉及到继承关系。
Interface Segregation Principle（接口隔离原则）： 满足。本次作业没有涉及到接口。
Dependency Inversion Principle（依赖反转原则）： 基本满足。
3. 程序 Bug 分析
与上一次作业一样，功能上没有bug，而因为性能太差产生了 bug，特别的是这一次的bug与上次是同一个bug，错在同三行代码，名副其实的祖传 bug。
4. 互测策略
在这一次作业的互测流程中，我主要运用了大佬分享的自动测试包，对我的和互测屋里的同学的代码进行测试，结果比对，命中率不算高（可能由于评测机不太稳定？）。
心得与体会
第二单元的作业感觉除了关于处理线程安全和多线程调试的问题，总体比第一单元更好写，更不容易出错。
而要处理好线程安全，我们可以直接使用线程安全的数据结构，也可以在设计上处理好wait, notify 和锁的关系避免出现bug。
设计原则上，我们需要在设计阶段就考虑单一功能原则和开闭原则，避免写出不可拓展的代码，或者耦合度过高的代码。