00作业总结

由于我是重修的，所以第一次作业没有做，总结就直接讲第二三次作业的一些收获和困惑。第二次作业做得非常差，整个思路不对也没弄清楚作业指导书中的意思，好在第三次作业及时补救。不过最后编译完成时对于输入还是出错了，导致了设计的三个样例都报错显示输入错误，但是代码整体逻辑应该是符合的。

第三次作业总结和bug

第三次作业主要是在第二次作业傻瓜调度电梯基础上加上捎带功能，我选择的是加上一个控制器类处理捎带功能。我估计主要bug就是出现在加入schedule方法时对于程序整体架构考虑不周到，一但输入请求中出现了捎带之后就会逻辑运行出现bug。最后测试来看拿第二次样例测试倒是可以，单独的简单捎带也可以，但是出现上下楼后再有捎带的情况逻辑判断就紊乱了。挺头疼的暂时还在调试，怀疑这个部分可能得推倒重来。

相较于第二次作业还有以下的一些变动：

1、更好的刻画数据中的结构

对于Request类，并不是按照字符串来存储的，而是分成几个具体的int，double，boolean类型的参数来存储的。这样减少了使用此对象时候的操作。

2、简化类方法的职责

在Elevator2类中，使用了代码很少的方法，如reset（），这个方法是一个任务完成时，把电梯里该楼层的按钮上的灯取消的。这个方法就很简单，尽量保持每个方法只做一件事情。

3、增加额外的数据管理类

在我的代码中，由于顺路，会让电梯的运动目标增多，我在电梯类中，新增了一个TREESET类对象，用来存储所有的运动目标，这样很大程度简化了请求队列的代码量。

度量分析

这一块安装出现问题，安装了metrics之后报错无法打开metrics view页面，我先这样上传一下博客免得没提交，再看看能不能安装。

类图

当前的设计中有Floor, Request, RequestQueue, Control, Elevator这几个关键类。其中，Floor的职责是存储楼层的状态；Request的职责是存储单个指令的内容；RequestQueue的职责是存储一系列指令的内容；Control的任务是获取当前时间内可用的指令，并且把它们分配给各个电梯；Elevator的职责是维护电梯的状态，并且将调度器给的指令进行智能调度后运行。

对各个类的职责进行分析，Floor Request RequestQueue类的功能十分明确，类的方法设计较为合理。但实际中Control和Elevator的职责较为冗杂不明，好的设计中Control应该仅负责指令的调度排序后分配给各个电梯。而Elevator的职责应该仅仅是执行调度器分配的指令，而不存在智能调度的作用。

心得

之前学过java但是没有系统性的使用java进行过项目编译，直接一来就是这个内容让我压力有点大，很多东西都一知半解而且不习惯于java eclipse的IDE，但是用平时用的Android stdio那会更加懵逼，连提示都不好用，所以目前熟悉了些eclipse还好。再就是编译的思维还是不行，鲁棒性太差，第二次作业和第三次作业练习紧密，但是我写完之后进行改动发现之前的很多东西得推翻重来没有留下接口呢，还不写注释，一回头自己都不记得这东西是为了什么留的。