作为一个之前从未使用过java语言，主攻面向过程式编程的“面向对象”小白，于是乎从第一次作业开始时利用时间疯狂学习java语言，经过三次作业的残酷洗礼，自己对面向对象式编程多多少少有了初步的了解（前路漫漫，任重而道远）。下面针对之前的三次作业进行总结分析，以及自己这一个月来的心得体会。
第一次作业：一元多项式加减运算
这次作业可谓是与“面向对象”和“瞌睡虫”对决的开始了。第一次接触这门语言和这种思想，还没有养成相应的思维习惯，于是基本就是按着面向过程的思路来完成的。整个程序只有一个主类、一个主方法（所有处理都放到主方法中去了），值得庆幸的是用到了正则表达式（现学现用）来规范输入。主方法主要是开了四个数组来分别存储结果多项式与输入多项式的的系数和幂，进行相应运算，利用数组下标和幂相等的关系遍历数组来实现升序输出。
公测被测出的bug是压力测试的分支点，因为输入太长的原因程序没有输出预期的结果。互测被测出的bug是由于判断同一个多项式不能输入相同幂项那里逻辑不够严密，导致同时输入几个相同0次幂项时程序不报错。分析之后程序应该就是不能判断相同的0次幂项，其他没啥大问题，看来自己测试的时候还欠缺考虑啊！
至于我测出的bug，先是看了一遍被测者的格式规范判断，他也用了正则表达式，但跟我印象中的略有出入，于是就在格式的边缘疯狂探索，终于找到了他的格式错误。还有就是我自己准备的杀手锏（自己一开始写的时候容易忽略的地方），就是第一个多项式前有符号的情况，那位老铁没有考虑到，也被我给逮着了。
下面是我的度量分析和类图（也就仅仅一个孤独的类而已）
通过metrics图能够看出main方法的圈复杂度过高，块嵌套深度过深（毕竟自己所有处理都放到main方法去了……）。
第二次作业：傻瓜电梯
这回照着指导书写了几个类，姑且算是套上了面向对象的外衣，Request类里只有请求的属性和构造方法（这或许是我写的最自豪的一个类了），RequestQueue类里我将数组的计数器和数组当做静态变量使用（emmmm,这似乎悖与数据封装），方法就是将有效的请求存进数组。主类的main方法主要是处理输入字符串和输出错误情况的事情（不敢在main方法里放太多东西了）。而对于Scheduler类，唉！还是来看度量分析吧！
一如上次，还是这两处变红，看来我的调度器还是写了太多东西，判断同质，输出电梯状态等处理都放到Schedule方法中去了，使用了过多的条件判断语句。
这回被公测测出了两个bug，一个是没有判断输入时间过大应该报错的情况（真应该抽自己一遍为什么不仔细去看指导书的要求），另一个是没有忽略不同时刻的同质请求，这回真的是自己疏忽了，没有考虑到当一个请求发出时间大于电梯时间的情况，导致时间错误，没能判断出同质。
这次整八百遍我还是没找出那位老哥的bug，于是就从readme下手，还真找到了一个输出与readme规定不符合的bug（看来检查一下readme也是一件重要的工作啊）。
总体来看，相比上次作业有了一点点进步吧，但是对面向对象的思想了解还是不够透彻，还需要进一步学习。
第三次作业：有一点小聪明的电梯
电梯耍了一次小聪明，我却不得不用几天几夜的爆肝来应对。虽说表面上只是加了捎带这一个功能，但细细分析似乎捎带跟同质缠在一起，还是挺复杂的。这次的核心部分是再写一个新的调度类来适应新功能。电梯在往上的过程中，每到一个楼层就寻找这个楼层需要捎带的请求，然后执行的同时也判断该捎带请求的同质请求，将其标记，不再执行同质请求，对于执行过的请求，也进行标记，不再执行。
通过度量分析可以看到，我这次的程序虽然实现了功能，但是几乎全部功能的实现都在Schedule_son这个方法里，代码显得臃肿，重复性很高，这是一次很大的错误，值得反省，类之间的分工不均衡，这是目前自己程序的最大问题。
这次公测倒是没有bug，互测阶段被测出的两个bug几乎都是判断条件不充分引起的，因为同质引发的错误，因为代码臃肿，改起来工作量也不小，自己看的眼都花，有这种错误也是自己设计方面的问题，自己的思想还不够深入。
这次拿到的同学的代码很漂亮，没有什么bug，其实互测也是一个学习的过程吧，至少我看到自己的不足。
最后的心得
1.千万千万不要拖，如果因为拖延症而“死”，相信你自己也不痛快。
2.看清指导书的要求和理解指导书的需求，先清楚自己要实现什么才开始构建动手。
3.坚持写完，不要有那种认为没时间了、太难了写不了的思想，坚持写，就算还写不出，也总比放弃好。
4.程序在进行格式检查的时候使用正则表达式是个不错方法。
5.使用try-catch，不要让自己的程序出现crash，这是大忌。
6.在提交之前要仔细检查，自己多测几遍，看一下readme的规定是否与自己程序实现的一致。