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挑错之前，为何不想想自己的问题出在哪里？为何不考虑自己的程序为什么没有完善？所以保持一个良好的心态吧。

 

转载于:https://www.cnblogs.com/y1027/p/8712454.html