第四次作业——前三次OO作业的总结

由于本人对面向对象极度缺乏理解，故每一次作业的实现都异常丑陋，虽然使用了类与方法的思想，但将各个类与方法都定义在一个主类里面，全部工程由一个文件构成。故无法生成有意义的类图。

第一次作业——多项式计算

1.自我程序分析

第一次作业是多项式计算，我只使用了一个多项式类，输入输出全部写在main类里面。计算的时候是以单项式为单位进行计算的。且是第一次使用java写面向对象的程序，难免显得生疏僵硬。故整体显得非常呆板。以下为第一次作业的度量分析。

 

可以看到main函数非常的冗杂。

运用正则表达式对输入的字符串的格式进行判断，再进一步提取出字符串里面的有效数字进行计算。

2.自我bug分析

公测与互测均无bug。

3.互测策略分析

对方公测出现了四个bug。互测时使用了特殊的0前有正号和负号数据，找到了对方无法处理该类数据的bug。

第二次作业——电梯调度

1.自我程序分析

过于面向过程的程序风格因为个人的惰性还是没能改变，仍然不能体现出面向对象高内聚，低耦合的思想。

以下为第二次作业的度量分析。

按照输入顺序执行每一条指令即可。

2.自我bug分析

公测出现了两个错误，原因是相同的：对于正则表达式的运用不够熟练，没有在正则表达式里面加入开始与结束符。

互测中没有出现更多的bug。

3.互测策略分析

未能找到对方的bug。对方公测也没有出现bug。

第三次作业——ALS电梯调度

1.自我程序分析

面向过程的不良习气甚至更加严重了。。。。

 

可以看到process方法里面过于冗杂，我实现的时候也发现这个方法太长，非常难以调试以及维护，也因此产生了大量的bug。

实现方法大概就是维护一个捎带队列，若队列为空则将所有请求中最靠前的还未被执行过的请求设为主请求，再看哪些请求能被它捎带。若处理完主请求后捎带队列不为空则将捎带队列中的一个请求设置为主请求。

2.自我bug分析

公测bug出现在捎带的判断上，而互测时对方找到了我因为疏忽大意而产生的一个bug：第一条指令必须是（FR,1,UP,0）。而我的程序则可以不是这样，只要时间为0就行。

除此之外对方还进一步找到了我捎带处理产生的bug。

3.互测策略分析

对方的程序写的很好，十分规范，我用了很多方法构造了许多极限数据以及进行对拍都未能找出对方错误。

 

总结

这三次作业使我对面向对象有了一个更深的了解，虽然写出来的程序仍旧是不够面向对象，但我认识到了自己的不足，并会对自己的编程习惯与方法进行反思与改善。希望自己在以后的学习中能克服拖延症的毛病，早早开始进行设计与实现，不再每次星期二晚上鏖战到天亮。