OO第一阶段做业总结

         对于OO这门课，学长学姐偶尔提起，你们都略有耳闻，可是并无将其和计组相提并论。所以，在刚开始接触的时候，并不认为其会比计组难到哪里去，然而事实证实，仍是不要想固然去判断，以及不提早学好JAVA对于OO这门课会下降不少的生存率。

代码度量分析程序结构：

       第一次做业

       Metric度量分析：

             在度量分析中，能够看到第一行是红色标注的，这反映的是一个模块的复杂程度，而第三行反应的是各种的嵌套深度。从中不难看出，我所撰写的某个方法过于复杂，这是因为我将正则表达式的匹配加之对其是否正确的判断以及最后的输出功能都放在了这个方法中，所以出现了这个方法过于复杂的状况。从根本上来讲这是因为第一次接触java语言，对于面向对象的思想仍是不够理解，本质上仍是撰写了一个偏面向过程的程序。所以，应当将每一个功能细化和分开，这是十分重要的。

 

       类图：

       发现的bug、设计思路：

      第一次做业我自认为是测试得比较详尽的，然而却忽略了指导书上提到的一个点，致使了三个测试点错误，那就是当系数为0时，不打印这对数。我当时并无仔细去看指导书，对于这点要求是真的没有看清楚，这让我十分懊恼，也让我懂得了指导书是很重要的一个东西（还有readme）。惭愧的是，此次做业中还有一个bug没有被公测和互测测出，从而致使了第二次做业的失误。   

      在设计上，我将正确匹配到的数字存入一个大数组，而后用dividenum()方法将其分割为系数和指数，而后进行同指数合并并计算排序，思路简单，可是实现复杂。而且正则表达式的匹配功能并不完善，判断过于复杂和繁琐，以及对于数据的边界状况并无进行很好的测试。

 

       第二次做业

        Metric度量分析：

       

         在第二次做业中，一样出现了方法过于复杂的状况，也就是第一行所标注的get_list()方法，我将读取字符串，处理字符串，存储正确的字符串这三个功能，都放进了这一个方法中实现，所以过于复杂是理所应当的，同时还出现了第二行所标注的问题：参数过多。因为要实现这巨大的功能，所以大量的参数和变量是必不可少的，这就显得程序的这个方法模块很膨胀，可读性很是低，而且致使我在后来debug时十分困难，连本身都记不清楚这些参数变量表明的含义，还得花时间去回忆和从新理解，得不偿失。可是此次的做业更“OO”了一点，也就是更加的面向对象化了，对这种思想有了更进一步的理解。

        类图

       发现的bug、设计思路：

       在我认为第二次做业已经测试得足够完善时，公测结果又一次活生生的打了个人脸，个人程序在公测中crash了，缘由是数组越界。此次的做业要求实现一个傻瓜（FAFS）调度电梯，而且要求不符合要求的无效请求需马上给出反应。所以个人程序设计成，当输入无效时，指针减一。但若是第一条指令就错误的话，数组的指针就变成了-1，也就是越界了。这也就致使了在公测样例中，只要涉及到第一条指令无效，那么我就错了。emmmmmm，越想越气，这就比如你吃鸡捡了个空投，你捡了一把AWM可是子弹忘带走了。

      此次做业的难点在于判断同质，个人方法是从后往前判断，而且将指令分类为：UP,DOWN,NULL(ER)，只有后一条指令和前一条指令类型相同，而且开始时间在前一条还未执行完成时，指令才会判断为同质。这个方法存在着一些小bug，当时我并无de出来，可是在第三次做业中发现了，追悔莫及。

     

      第三次做业：

      Metric度量分析

        第三次做业一样出现了方法过于复杂而且参数变量过多的状况，一部分缘由是由于第三次做业是在第二次做业基础上的继承和重写，而且要求实现捎带功能。而我在ele_start()这个方法中，一是传进了过多的参数，二是在函数中既要判断同质，又要判断捎带，同时还得打印正确输出。能够说这个函数几乎完成了我整个程序的主要功能。这样的好处是，嗯，方便管理整个程序的运行状况，坏处依然是可读性极差，致使了我一点都不想debug。实质上，这个几乎万能的方法是不符合OO的基本思想的，对此我也十分惭愧和懊悔。

 

       类图

 

       发现的bug、设计思想：

       第三次做业是我测试得最为粗糙的一次，因为时间没有安排好，致使几乎没有时间去debug和发现问题，所以捎带存在的问题很大，尤为是同层实现两个请求，而且是捎带请求时，不能很好的作出判断而且实行，同时连续两个捎带时程序也会出错，这也是因为我考虑不够周到形成的。可是在此基础上对第二次做业的改正是十分有效的，并无重复出现第二次做业的bug，对正则的使用也更加驾轻就熟。

       捎带是此次做业最主要的功能实现，个人方法是使用一个变量loca，记录主请求的位置，而后判断接下来的指令存不存在捎带的状况，若是存在，就选择一条最优，也就是离当前楼层最近的请求执行，当执行完全部捎带请求后，回到loca的位置，执行主请求。惋惜的是，我花了许多时间也没有de完个人bug。

 

心得体会：

        1. OO这门课必须花费大量的时间和精力去学习和体会，不只是面向对象的思想，还有设计思路的逐步完善和成熟，在动键盘前，应该至少有一个完整的设计思路，这样才会节省更多的时间，而且必须认真去理解指导书想表达的含义，readme也必须认真的去完成和说明。

        2. 对于这门课，良好的心态是必要的。在身边的就有很多例子，互测的双方由于对方比知道本身的姓名而肆无忌惮。也有人跟我吐槽，一门课把整个系的阴暗面都展示出来了。我并无遇到对我而言十分过度的人存在，咱们并不能以一律全，只能以一个良好积极的心态去面对每次挑战。在抱怨别人给你找出bug以前，或者在给你readme挑错以前，为什么不想一想本身的问题出在哪里？为什么不考虑本身的程序为何没有完善？因此保持一个良好的心态吧。