BUAA_OO_2020_Unit2_Summary
第五次作业
第五次作业作为多线程的初见，给我带来了不少心理压力。在动手Coding前反复阅读了多线程教程，选择采用了较为简单的生产-消费者模式、Java中自带的线程安全容器等。至于调度策略，则采用了比较常见的Look算法。
程序结构分析
UML图
采用生产者-消费者模式，由InputThread读取请求并存入请求队列，由ElevatorThread派发请求给电梯，电梯自行决定如何运行。
类、方法度量
可以看出复杂度主要集中在电梯运行相关的方法，尽管采用了静态方法把电梯运行和管理（选择运行策略）剥离，但对降低复杂度的作用比较小。
Bug与互测分析
在强测和互测过程中都没有被hack，Look算法的性能总体不算最优，但还不错。互测阶段利用Python实现的多线程自动评测机在本地能hack出来，但由于多线程运行的不确定性，这些样例的bug复现率极低，提交上去后均hack失败。
第六次作业
第六次作业相比第五次作业对多线程的进一步学习基本没有什么要求，唯一的难点可能就是动态添加电梯，采用线程安全容器的话问题也基本迎刃而解了。但是没有利用功能实现的简单性来设计更好的优化策略，只是简单的采用了判断是否可稍带及由电梯抢占请求的策略，性能比较差劲。
程序结构分析
UML图
架构相对于第五次作业几乎没有改变，只是把分派请求给不同的电梯的方法作为静态方法集成在了Manager中。
类、方法度量
类：
方法：
总理来说复杂度还是集中在电梯类中。
Bug与互测分析
同样没能hack出room中其他同学的bug，但强测和互测中均被hack了一个测试点，再次测试不加任何修改的提交后修复成功，说明自己应该还是存在线程安全方面的bug。由于是在是复现困难，在本地试图复现多次无果后，遂放弃。
第七次作业
第七次作业相较于前两次作业主要是为电梯添加了不同的属性，由此给分派任务提出了一定要求（功能性方面换乘的正确性要求和性能的要求）。最终在调度方法上采用了静态的换乘调度策略，并且选择不让新增电梯参与到换乘中，性能得分还算理想。
程序结构分析
UML图
架构方面改动不大，主要是新增了解析换乘的TransParser类。
类、方法度量
类：
方法：
复杂度集中在了电梯类和换乘解析类。换乘解析类的复杂度偏高的原因主要是由于采用了静态的换乘解析策略，存在不少if-else分支。
Bug与互测分析
没有hack到别人，也没有被hack。
可拓展性分析
在这一单元中，我的第六七作业都是在前一次作业的基础上进行迭代而不是重构，说明我的架构是具有一定的可拓展性的。但是如果再结合SOLID原则来审视自己的架构的话，就发现自己还是有很多的不足之处。
- SRP：严格按照生产者-消费者模式，采用静态类、静态方法来剥离调度。新增功能时基本只用对调度器进行修改。
- OCP：做的不是很好，没有采用扩展的方式适应新需求，没有面向接口编程。
- LSP：没有类的扩展，做的不是很好。
- ISP：没有设计接口，做的不是很好。
- DIP：做的不是很好，没有层次化设计。
心得与体会
- 这一单元自己的注意力完全集中在了多线程上，而对面向对象的继承和抽象的认识则几乎没有进步，也没有运用到这一单元的作业中。
- 自己在第一单元中对于迭代一直有一个误区，那就是在不知道之后的需求时如何保持可拓展性。曾经我认为只能是查找往年的指导书，直接按照最终需求来设计架构（即使是这样第一单元还是次次重构）。但是在经历了第二单元的次次迭代后，我意识到这完全是自己架构的问题。如果架构本身的可拓展性强，比较符合SOLID原则，迭代起来自然得心应手。毕竟这门课的名字是“面向对象设计与构造"，而不单单是”面向对象编程“。我相信学习优秀的设计模式并掌握构造优秀架构的能力才是对我们最终的要求。因此，自己在今后的作业中，尤其是某一单元的第一次作业中，应当尤其在架构设计方面下足功夫，保持良好的可拓展性。
- 不要重复造轮子，线程安全容器真的香。
- 由于多线程的玄学不确定性，据我观察，这三次作业我所在room的活跃度都比较低。可能bug的难以复现浇灭了同学们hack的热情。
- 实验课的体验总体不如课下的作业，错误的或是叙述不清楚的指导书是导致体验变差的主要原因。但仍然感谢老师和助教们的付出，实验课对于快速掌握一种或多种设计模式的帮助还是很明显的。
