OO第一次课程总结分析

---

　　做为一个以前从未使用过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的规定是否与本身程序实现的一致。