OO第一次学习总结
1.第一次作业：多项式加法
从未接触过java的我，在从输入输出开始学了几天后，按照C语言的思路，写出了一个与面向过程极其接近的程序。
在这个程序中，存在两个类：一个是ComputePoly，用于验证格式、提取以及传递多项式参数；还有一个是Poly类，用以多项式的存储与计算。
从下图可以看到，程序总共有94行，而main方法有47行，占了一半的行数，说明该程序的总体思路仍是停留在写C代码时的面向过程思想上，将大部分的处理操作在main中逐步实现，而不是分摊到类中，从而导致main方法规模过大。
另外，在main方法中，采用了较多的if-else语句进行判断，并且嵌套了两次while循环，导致图中显示的圈复杂度较高，使得代码质量较低，并且不利于维护。
因此，在程序的设计上，应当将功能更好的分配，不再将大部分的功能堆积在main中，而仅仅将几个简单的方法分配出去。例如将对格式的判断以及数据的提取单独写过方法。
2.第二次作业：单部傻瓜电梯
本次作业中属性个数为16，方法个数为22，平均规模为6.8行。
Elevator类：属性个数6个，方法数7个，方法规模66行，内聚度0.611.主要存储电梯运行状态的各个参数，以及进行电梯状态的更新以及打印，故内聚度不高。
Request类：属性个数5个，方法数6个方法规模19行，内聚度0.24。主要构建一个存储请求各项参数的对象，方法仅供于调度器判断同质请求所用。
Reqlist类：属性个数3个，方法数4个，方法规模7行，内聚度0.333。主要通过传递进来的请求构建请求队列，并实现出队入队操作以供调度器调度。
Scheduler类：属性个数1个，方法数2个，方法规模7行，内聚度0。该方法中，command方法用于调取队列内请求并通过Request内的方法进行同质的判断。但该功能分配上显得不太恰当，致使了调用的深度过大，存在一定的缺陷。
Floor类：属性个数1个，方法数3个，方法规模54行，内聚度0。该类中存放了main方法进行输入请求的格式判断以及调用Request进行存储。与第一次作业一样，仍然存在着将部分功能放于main中实现的缺点，体现出对于程序功能的分配上仍存在的极大的不足。
3.第三次作业：捎带功能的电梯
Floor类：属性个数7个，方法个数2个，总行数47行，内聚度0。
Request类：属性个数6个，方法个数3个，总行数15行，内聚度0。
Reqlist类：属性个数6个，方法个数5个，总行数9行，内聚度0。
Elevator类：属性个数6个，方法个数4个，总行数34行，内聚度0。
Sch类：属性个数6个，方法个数4个，总行数134行，内聚度0。
本次作业中，可以看到代码行数达到342行，但由于经验、交流的欠缺，导致其均在同一个.java文件中实现，故类图中看不出相互之间的调用关系，且影响了代码的整洁性以及规范性。
除此之外，可以发现代码的块嵌套深度很大，这主要是由于相互调用时，由于不断的出现bug，导致不断的增加判断条件以及调用方法，致使程序结构越来越复杂，可读性降低。导致这种情况出现的根本原因还是在于实现程序功能时对于程序各个类的方法分配上出现了错误，使得类中包含的方法极为不合理，为调试也增加了难度，难以发现一些潜在的bug。
在完成这次作业时，程序的设计完成主要还是在发现bug的情况下不断对原程序增添判断条件和功能，但由于检测的不完全以及判断条件的设计的漏洞，还是难以避免的出现了一些未避免的bug。
二、自己程序的bug
1.第一次作业：多项式计算
本次作业中公测发现一个bug，互测未发现bug。
公测中未过的测试点为一个多项式内部存在多个同幂的项的情况。按照规则应当对于此类现象予以报错处理，但由于第一次的不熟悉，使得在设计程序的过程中，在readme中声明将多个幂相同的项进行合并处理，导致公测未通过。针对此项bug，仅需在读取计算过程中增加一个判断的数组即可，之前已经读取到的幂所在的位置置1，还未读取到的置0，这样便能避免该类错误。
2.第二次作业：单部傻瓜电梯
本次作业中公测发现一个bug，互测发现两个bug
公测中出现bug的主要原因是在double类型的时间T的输出格式上。在程序中，对于double类型的输出是直接print，导致其随着位数的增大输出时自动输出为科学计数法形式，而不是保留一位小数的标准格式。此项bug可通过String.format（“%.1f”，T）解决。
互测中的一个bug的出现原因同公测一致，故不再叙述。另一个bug出现的原因是对于请求的处理项数出现偏差。在readme中声明的是处理100条请求，并在输入100后自动运行程序，然而在main中对输入的判断、计数上出现偏差，判断条件中本应该是sum>=100则开始运行，但却遗漏了=号，致使在输入100语句后，程序仍然在等待输入，因此而导致程序错误。
本次作业中出现的原因均是由于对于自己程序检测的不细心，在通过几个小样例的测试后就弃之不管，导致付出了较为惨痛的代价，也算是一个警告吧。
3.第三次作业：捎带功能的电梯
本次作业中公测未发现bug，互测中发现3个bug。
互测中的bug均是由于在对FR请求的判断处理中，存在着时间的判断漏洞，导致对请求队列的请求处理中出现错误。例如在主请求处于开关门状态时进行了同时刻的错误捎带，导致程序执行结果出现错误。主要原因还是在程序中对于请求的处理时，判断条件的复杂导致调试难度增大，并且可读性较低，不易于发现设计上的漏洞，这才使得在开关门的边界条件上的判定条件存在漏洞，并在三种情况下出现了bug情况。而这无疑又是一个测试不全面导致的惨痛教训。
三、分析他人程序bug
在拿到别人的程序时，一般在无注释的情况下十分难理解对方的设计思路，并且有些变量名的选取更是增添了对于程序理解的困难。
因此我一般是先阅读对方的readme，分析其与指导书的要求以及部分潜在要求是否存在不符，并与自己的readme对照，以查找当中可能存在的漏洞，这样便能很快的构造相应的输入检测出bug。
随后，若是对方的readme不存在明显的漏洞，则会通过自己构造的样例不断的对其程序进行测试，并在此过程中了解其程序各部分的功能与联系。在自己构造的样例中，若是出现bug则顺着程序执行步骤找出相应的错误原因，若不存在bug则会对于其在readme中提到的部分特殊情况下的自定义反馈结果进行测试。
四、总结体会
在这几次作业中，最大的感触还是自己对于java语言的了解程度较低，并且不能很好的将一个作业中要实现的功能合理分配给各个类中，大体上沿用的思路还是偏向于面向过程，习惯将部分的程序功能实现堆积在同一个函数方法中，导致该方法代码规模增大，导致调试难度也较大。除此之外，还存在着对于自己程序检测bug的不全面导致的问题。
由于自己本身的java掌握不够，故在日后的部分精力应放在对于互测的大神的代码的学习上，通过对于他们代码设计的分析，学习其模块的合理分配，尽量使得各模块之间相互独立。
除此以外，还应改善的是对于各个类的方法的设计，避免某个类的某个方法规模过大，且避免if-else的多层嵌套问题，否则将很难避免bug的出现。
最后，还是应当加强与其他人的交流，多听听他人对于作业设计的看法以及对于作业规范设计的理解，进一步降低bug出现的可能。
