千里之行，始于足下。
-
不知不觉，面向对象的学习已经完成了三次作业，虽然只有短短三周，但是在这期间，我们的能力得到了很大的提升。
作业分析
第一次作业
类图
poly类:多项式类，支持多项式的加减运算与打印方法.
computer类:主类，用来读取与调用poly类。度量图
分析
- 第一次作业是写多项式加减，在这一次作业过程中，复习了JAVA的基本语法，并且学会了正则表达式的使用方法。
在类的使用方面，我只将表达式设为一个对象，在主函数中进行加减，现在看来还可以再分的细一些。 -
公测与互测：
公测中未出现错误。在互测过程中，被对方找了两个bug，一个是对于一个空的{}多项式，没有在说明文档中说明应该返回错误或者正确，这也提醒了我要写清楚说明文档，第二个是对于负数指数的判断，这个是由于在修改bug时出现错误，也就是没有测之前出现过的错误，让我吸取到的教训是，应该在每个修改的版本后测试所有自测点。
在测试对方的过程中，也找到了一个bug，我测试的程序在判断大数据时，会因为数据太大而出错，这也是因为正则表达式本身栈有限，对方没有注意到或者修改的不够完美而出现的错误，这也提醒我要多测边界数据。第二次作业
类图
exphandler类：非法时用于输出信息。
floor类：楼层的信息，发出请求
elevator类：电梯的基本信息，发出请求。
require类：请求类，其中包含请求的基本信息，包括时间楼层等。
queue类：队列类，由请求组成的队列，用于弹出与寻找请求信息。
scheduler类：调度器类，根据时间顺序从queue中得到请求，并将请求完成，同时判断是否为同质请求。度量图
分析
- 第二次作业开始编写傻瓜式电梯，也就是不支持捎带的电梯，模拟电梯的运行。
从上面的类图也可以看出， 关键点就是电梯类，调度器类与请求类的关系编写。现在回头看自己代码，还是有很多地方比较面向过程，比如调度器部分同类请求的判断，如果写成靠电梯类本身去判断会更好。 -
公测与互测：
这一次的公测与互测均为出现bug，同样也没有发现对方的bug。第三次作业
类图
基本继承的第二次作业的类
controller类：继承scheduler的新的调度器类，调度方式为根据捎带来判断，所以按照楼层一步步运动时判断是否要捎带。度量图
分析
- 第三次作业是在第二次作业的基础上增加了支持捎带的功能。也就是要让你的调度器不再只根据时间，还需要根据是否顺路来调度需求。
我的写法是根据时间线，也就是电梯在运行主请求过程中，每上升一层就判断一次是否有捎带请求，感觉还是比较暴力的，不过这样不容易出错，而且可以准确的判断是否捎带，在代码实现的方面，我认为我的不足之处在于调度器类的继承没有做好，基本上是重写了这个调度器，现在来看有些共同之处还是可以继承的，这也跟我第二次作业中的调度器可扩展程度不高有关，我还需要在这方面多下功夫。 -
公测与互测：
这一次测试也没有被查出bug，也没有查出对方的bug。自测分享数据多花时间非常重要呀。度量分析
-
三次作业的红色部分都是圈复杂度过高，也就是分支过多，这说明我在对象的使用方面还是不够熟练，比较偏向于过程式编写，还需要在这方面多花功夫。
心得体会
- 不足：
（1）对于readme的编写不够细致，很多小细节没有完整的编写进去，作为一个工程的阅读文件还是很有必要认真写的。
（2）程序编写过程中，还需要多使用面向对象的思想。
（3）还需要多学习他人写代码的方法，提高自己代码的简洁性。 继续保持：
（1）从任务下发开始构思，不能拖延工程。
（2）磨刀不误砍柴功，先把框架构筑好再编写代码，以免后面再打补丁，影响程序可扩展性。
（3）自测一定要完备，尽量多花时间在测试自己的程序上。
