OO的第一次死亡

　　久仰OO大名，总是想着提前做点准备，其实到头来还是什么准备都没有做，所以这学期就是从零开始的面向对象生活，也因此遇到了很多的问题。

• 第一次作业——多项式加减

　　第一次作业历来是较为简单的，但是对于面向对象零基础的人来说也是有所困惑，到底什么样子的代码才算是面向对象？初次见识java，完全体会不到面向对象的思想，因而在代码编写中透露出了一股浓浓的面向过程思想，基本就是照着C程序改过来的，勉勉强强写了个Class上去，然而还是main方法干的活多，只在Mult_to_operate类中写了几个简单的操作多项式的方法，而在main方法里输入数据，判断格式。这样子的代码根本就是一个C程序的翻版，毕竟自己当时真的就是java零基础。

　　第一次作业的度量和UML图:

 

　　由于是第一次使用正则，理解的不是很透彻，因此发生了正则爆栈的问题，但是为时已晚，也没有想到解决办法，只有使用try-catch大法来如实报告自己的错误，导致最后一个压力测试的测试点没过。对于格式的处理，本想使用状态机来判断，于是将C程序的状态机复制过来，但是立马发现了很明显的错误，没有对最后一位符号进行判断。这也是我在互测时寻找别人BUG的方法，因为我遇到的那个人就是使用状态机来判断格式的正确与否，因此着重考虑了式子的最后一位，最终发现了两个BUG+一个数组越界的Crash。在互测阶段，被报告了一个bug，即多个前导0，而我在正则表达式中只匹配了一个0，这的确是疏忽大意了。

• 第二次作业——傻瓜式电梯

　　在做这次作业时，已经初步了解了面向对象的思想，在作业中也使用了五个类，多个方法去实现，其实对于傻瓜式电梯，如果能够明白电梯运行的原理，就会变的非常简单，无论是楼层请求还是电梯内请求，都是为了到达那一层，因此在运行时只需要考虑电梯要上行至要求的楼层还是下行至要求的楼层就可以了。但是在这次作业中出现了致命的错误，也是极为简单的错误——输入的指令不正确时忘记输出ERROR，其实如果这里没出问题的话公测肯定是全过了，互测阶段被报的BUG也是这个原因。这次作业其实非常简单，由于不需要考虑捎带，完全没有自己一开始所以为的那么困难，而自己在互测阶段也没有能够发现别人的BUG，毕竟这次作业的逻辑很简单。

　　本次作业的UML图和度量：

　

　　在这次作业中，elevator的内容过少，只有设置楼层和读取楼层，而requestline几乎就是将request重复了一遍，而Floor类是几乎没有什么用，就把他当做主类来运行了，而绝大部分的工作都是由Scheduler类实现，它干的活最多，每个类的方法分布非常不均匀。

• 第三次作业——可调度电梯

　　可调度电梯相比于傻瓜式电梯，也只是多了一个条件，就是能够捎带，而其余的运行还是和傻瓜式电梯一样。

　　我个人的做法就是首先将当前指令加入到一个小“队列”中，然后对当前指令进行判断是否存在能捎带的指令，如果能够捎带，就把能够捎带的指令往小“队列”中添加，判断了一遍之后再从当前指令开始再次判断一次，因为在第一遍扫描过程中，最终完成的指令可能已经发生了改变，因而可能有新的指令能被最终指令捎带上，通过这种判断方式，就能够生成一条小“队列”，然后开始运行这条小“队列”，小队列运行完毕后再从指令中寻找到下一条没有运行过的指令，开始创建新的小“队列”。

　　本次作业的UML图和度量图如下：

　　

　

　　这次的代码由于基本是照搬上次的代码，导致在修改时，承接了上次的思想，因而导致Scheduler类更加臃肿了，由于判断失误，而最后时间不充足，没有充足的时间去改正方法，导致出现了两三个代码相似度极高的方法，很是臃肿，其实可以简化很多的代码。

　　但是自己在最初失踪没有正确理解到捎带的概念，到底什么时候能够捎带，什么时候不能捎带，上行捎带和下行捎带的区别，这些问题自己的都没有弄清楚，最终在代码中出现了大量的BUG，经过不断的调试，勉强通过了所有的公测点，但是自己也意识到在某个地方仍然存在着错误，倒是对于稍长一点的测试数据就会出现问题，但已经没有时间去调整了，只有在后来才能进行调整，互测阶段被找到的BUG也是由于稍长的指令而出现的问题，初步定位在下行捎带的位置，因为自己在最开始误认为上行捎带和下行捎带是一样的。

　　互测阶段所得到的代码又是一个大佬级别，上行下行，基本都测试了，但是还是挑不出任何错误。

 

　　心得体会：

　　在OO课程的学习中，逐渐领会到了面向对象的思想，并能够将其运用到代码撰写中，虽然还是比较初步的思想，并没有深入，但是通过课程的逐步学习，已经逐渐掌握。其实对于java这门语言，语法基本不用学习，重要的就是面向对象的思想，否则完全就可以把java当做另类的C程序，那么这样子的java就失去了意义。

　　在撰写代码时，有一个清晰的思路极为重要，如果能够首先就将思路理清楚，知道首先干什么，然后再去干什么，同时要弄清楚原理，不能看的迷迷糊糊就急急忙忙的开始写，这样只会在后来的测试中发现更多的BUG，就比如第三次作业，如果能够好好的看清楚要求，在开关门时刻不进行捎带请求，那么后面我所遇到的很多问题都不会出现。在调整程序的过程中也要注意对于代码的改动所产生的其他影响，不能出现把这个BUG修复了，上一个修复了的BUG又冒出来的情况，这样子做完全是就是得不偿失。

　　测试程序时，首先要了解程序的运行机制，在每个关键区域都考虑一下是否会存在错误，如数组的边界等。读懂自己的代码容易，读懂别人的代码难，但是只要用心去看，总是能够大致了解到别人的思路，顺着别人的思路去思考，去测试，这样才有可能发现BUG，而一味的靠猜，靠试，是很难发现自己或者对方的错误的。