一、电梯作业的设计策略
自己的设计基于 blockqueue 框架。且三次作业都是同一个设计策略。
核心数据结构是一个阻塞队列，用于保存请求队列，其他模块主要是与该队列交互。
请求生成器：用于获得请求，并将请求加入请求队列。
请求调度器：用于将请求派给不同的电梯。
电梯：用于处理被分配的请求。
在第二次作业时，只是修改了电梯对于执行请求的策略，增加了捎带功能。
在第三次作业时，只是复制了两部电梯，其行为模式完全相同，但是请求调度器给其分配的请求种类有差别。另外，乘客在下电梯时，若其没到最终目的地，则由电梯修改其出发地后将请求加入队列。请求调度器无法区分由电梯加入的请求和请求生成器加入的请求。
二、代码分析
1、类图
由上可以看出，Customline 扮演着核心数据结构的角色，其他类主要都是与其交互。另外，ElevatroSimulation 扮演着启动其他线程以及最后关闭线程的角色。ElevatroManager 主要与电梯互动。
2、静态分析
Unutilized Abstraction: This smell arises when an abstraction is left unused(either not directly used or not reachable).
Cyclic-Dependent Modularization: This smell arises when a cycle appears in the model dependent graph.
自己目前对这些设计方面存在的问题还不能很好的理解，对于其导致的问题还没有经验。
Long Parameter List: 将关系密切的参数打包为类。
Complex Method: 识别出方法中逻辑集中的块区，将其封装为函数。
Empty catch clause: 不偷懒就可以解决。
Long Statement: 语句分拆解决。
Complex Conditional: 这能通过将条件封装为函数或者拆分条件解决。
Magic Number: 这能通过定义常量或者枚举类型解决。
NOF: Number of Fields, 其中 Elevator 的域明显有点多，可以考虑拆分。
NOPF: Number of Public Fields。
NOM: Number of Methods，可以看出自己实现功能的核心类是 Elevator, Customer.
NOPM: Number of Public Methods, 其中Customer占据了大部分，其提供的功能由其全体对象共享。
LOC: Lines of Code, 其中 Elevator 的长度超过其他类两倍，说明自己这一部分对于函数功能没有清晰划分，致使函数过长。
WMC: Weighed Methods per Class, 依然可以看出，自己的 Elevator 类提供了绝大多少功能，是核心类。
SOLID原则分析
- Single responsibility principle：每个类的分工都相对合理明确。
- Open closed principle：自己比较充分的考虑到了这一点。
- Liskov substitution principle：本次作业没有类的继承。
- Interface segregation principle：本次作业没有接口。
- Dependency Inversion principle：本次作业对于模块的依赖性考虑不够充分，层次性不够，出现了循环依赖的情形。
三、bug 分析
自己的 bug 的问题是：电梯每到新到一层楼后，应该先下后上，而我没有注意到这一点。
四、测试策略
通过随机多组数据，进行大规模测试。这样可以发现一些 bug。另外，如果阅读源码发现其有死锁或竞争条件，而测试运行正确，可以在相应位置加入 yield() 语句来促使错误情况发生来验证。
五、心得体会
1、线程安全
对于线程安全，核心是数据安全。如何保证数据安全，目前知道两种方法，一是由自己加锁，二是使用阻塞队列。综合自己和别人的使用经验，后者提供了一个简单而又强大的模型。在操作系统的学习中，线程同步中也有两种方法，其一是信号量，其二是管程，正好与 java 提供的两种方法对应。
2、设计原则
好的设计能够事倍功半。在这次的电梯作业中，由于第一次的架构设计合理，使得后面两次能够很好的重用，节省了大量的时间，且在已经验证过的代码上继续开发，也少了很多 bug。这其中，设计原则发挥了很大作用。比如我第一次作业时由于考虑到了对扩展开放、对修改封闭的开闭原则，使得之后的编码比较轻松。