OO第二次博客作业

1.前三次作业总结

1.第一次作业

类图：

复杂度分析：

第一次作业我一共用了两个线程来实现电梯和请求的获取，我专门设立了一个人的集合来储存请求，并将其分为电梯内和电梯外，人员的储存方式我是用的hashmap按照所需楼层来储存要到此楼层的所有人员的集合，因此每次调度器只需要考虑相应楼层，而不用考虑具体每个人，以此获取最大的查找效率。

第一次作业我采用的调度策略为sstf，即电梯每到一层就寻找离当前层数最近的请求，虽然可能会导致电梯的摇摆问题以及部分请求长期得不到相应，但是总体运行时间上却是极为优秀的。

2.第二次作业

类图：

复杂度分析：

第二次作业相比于第一次作业我并没有进行过大的改动，主要改变是由单一的请求集合，改为电梯外有一个整体的集合，每个电梯内部也有着所搭乘的人员的集合，调度器根据外部集合以及每个电梯的内部集合来获取请求，以及增加了一个电梯的工厂。

这次的作业我依旧采用的是sstf策略，每个电梯都寻找最近的楼层，为了防止多个电梯前往同一楼层造成浪费，我设置了一个冲突系统，即某层已经有电梯前往时其他电梯就不会去这层，以此实现电梯的总体调度。

3.第三次作业

类图：

复杂度分析：

第三次作业我采取了WORK-THREAD模式，相比于第二次作业，电梯基本上没有进行改动，由于电梯有了行动范围，因此我提前对每个请求进行了分解，并依次执行，调度器需要管理的只是每个请求组的第一个请求。程序架构上，personsWaitOut即外部人员集合与代码其他部分的交互可能过多，因此代码有着一定的耦合度。

调度策略上我采用了look算法，每个电梯都独立运行并根据所能执行的请求在相应楼层开关门。

2.bug分析

第一次作业比较简单，因此我并没有什么bug。

第二次作业由于我使用了两次System.in导致了线程的不安全，导致强测得了零分，让我认识到了线程安全的重要性。

第三次作业则因为缺少了一个判断条件，导致在莫种情况下电梯满员时会在某层不断地开关门，电梯无法终止，这主要是我的不注意以及测试的不完全造成的，实际上，在我使用了自动测试之后很轻易的就发现了这个bug，因此测试是十分重要的。

3.关于发现别人的bug

三次作业我主要是从调度策略上入手，先阅读代码，理解别人的调度策略，再针对性的生成数据进行测试，然而，由于生成策略的随机性过强，针对性依旧过弱，导致我并未发现bug。

4.第三次作业的可扩展性

关于程序的可扩展性，由于电梯和请求集合都只关注各自的职责，即执行请求和管理数据，因此这两部分的可扩展性较高，同时由于电梯工厂的存在，只需要添加属性就可以进行相应的改造，唯一不足的地方我认为是我缺乏一个对各个电梯进行统筹的调度器，目前的调度器基本上是根据各个电梯独立完成，甚至完全可以在每个电梯设置一个独立的调度器也没有区别，因此，一个统筹的调度器是提升程序延展性的关键。

5.心得体会

在这一系列的作业中，我成功学会了线程的使用以及交互，经过了第一系列作业的失败之后，关于面向对象的思想我有了比较深刻的改变，因此在完成这些作业的时候并没有遭遇多大的困难，甚至比较轻松，唯一的问题是我对于程序的测试依旧是不够重视，我所遇到的bug都是经过测试能够比较轻松的发现的，但我却疏于进行本地测试，因此，提升测试能力是我接下来的关键。