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，而一味的靠猜，靠试，是很难发现本身或者对方的错误的。