OO第四次作业

       转眼间OO前三次作业就结束了，直到现在还感觉这几周像是在做梦一样。总之就是一句话——信息量太大。首先，OO是个教你写作文但是不教你怎么拿笔的神课；其次，前所未有互评机制给我们带来了许多惊喜与苦闷；再者，OO那非常工程化的作业给我们的充足睡眠造成了不小的挑战。但是，正因为OO这几周给我们带来的巨大信息量，才使得我们对这几周OO之旅的分析整理变得有意义。

第一次作业

　　说到OO 的第一次作业，可以说是我们的老朋友了，因为我们曾经在数据结构课上写过链表形式的多项式加法和乘法，所以说我们对第一次OO作业的实现多项式相加并不陌生。然而，第一次作业看似人畜无害，实际另有玄机。首先，这次作业要求我们用C和java语言共同实现，C语言也就罢了，没交我们java却让我们用java实现是什么鬼。没办法，只能自学java，好在java和C的语法差距并不是太大，自学java的基础部分对于我们这些习惯烤漆预习的人还是比较easy的。第二点，相信也是所有初学者对OO这门课所共有的疑惑：我以前写函数写的好好的，你现在要叫我把函数放到类里面，还要用个变量才能调这个函数，这不是多此一举吗？所以，相信有一些同学硬生生把第一次作业写成了面向过程，而没有理解到类的封装功能的精髓。第三点，OO作业对鲁棒性的要求非常的高。由于互测找bug的奖惩机制，拿到你代码的那位同学一定会用尽浑身解数来找你的逻辑错，爆你的栈，甚至是严格比对你的readme和你的程序有没有冲突。所以，程序的鲁棒性是非常重要的。而要想提高程序鲁棒性，首先，熟读指导书必不可少，因为一切以指导书为准（即使出错你也可以赖在指导书上），要是你的理解和指导书出现了偏差，那后果不堪设想。其次，码代码前良好的构思是非常重要的，比如说第一次作业的非法输入分为好几类，有的是格式错误，这个需要我们自学正则匹配表达式来完成，这部分的错误可以在输入的时候就进行判断，而有的错误是同一个多项式内的指数重复错误，这类错误就只能在实际处理的时候进行判断。此外，由于一个crash错误要扣error错误的两倍的分，我们可以将main函数里面的所有代码全部用try括起来并且catch所有异常，当catch到任何一个异常是都正常退出，这样就能把所有crash错误转成error错误了。当写完代码之后，测试也是非常重要的，首先可以自己估摸自己变成中可能出错的地方测几组自己的数据，然后可以去git的讨论区里搜集同学们各种奇葩的问题输入来进行测试，并且和助教的标准回答做比对。在测试完毕之后，就是把自己的代码放到测试平台上的过程了，这一步万不可大意，稍微不留神就可能让你这次作业的努力白搭，建议上传到git上之后点进代码文件确认提交的版本正确。在OO测试平台上拉取的时候一定要确定hash一致，确保自己最后的提交是最新版本。Readme的私人信息处理也要完善，由于前两次作业必须用pdf形式，wps等软件在导出时可能存在一些问题，但是有大佬已经发了相关的帖子所以这里也就不再赘述了。关于发现与被发现bug的问题，我第一次作业发现了别人指数相同的一个bug，估计是这位同学忽略了指导书上的那句话吧；而我自己则被找到了正则表达式爆栈的一个bug，后来想到的解决办法是将表达式拆开分析，可以避免爆栈。

第二次作业

　　OO第一次作业其本身的作业内容要注意的不多，更多需要注意的是诸如测试，提交这样的一些细节问题。但是从第二次作业开始，OO这么课程就开始动真格了。如果说第一次作业只是热身，那么第二次作业就是实战了。第二次作业的内容是实现一个非常傻瓜式的电梯程序，但是毕竟这是一个综合性的程序（从指导书的长度就能看出它有多综合了），我们仍不能掉以轻心。首先还是要熟读指导书，建议多读几遍，将一些关键的部分（比如加粗或标红的地方）用自己的话写下来，虽然当时你可能认为记不住但是一些正确的片段记忆可能在你编程的时候带来潜移默化的影响。当对指导书中的规范比较熟悉之后，我们可以开始进行整个程序的构思了。正所谓磨刀不误砍柴工，在码代码之前一定要好好地构思，千万不要等码代码的时候脑子被绕晕了或者发现你少考虑了一些很重要的事情的时候再来后悔。。。（当然假如你是dalao那当我没说，orz）不光要对本次的程序进行完善的构思，还要联想到程序的可扩展性，大家在做第二次作业的时候可能都多多少少从学长学姐们处了解到了电梯作业不止这一次，也就是说你这次的代码很有可能在下次作业的时候还能派上用场，所以说千万别放飞自我在写程序的时候随心所欲地乱改。要不然等到下次作业的时候你需要用某部分代码但是你连你当时怎么想的都不知道（注释一定要写详细，简短的注释不一定有用（至少对我来说是这样））。细节方面的东西就不再详细说了，就说一点，关于时间模型的构建问题。我是用的for循环作为时间模型的方法，这个方法非常符合正常思维，但是缺点是当时间数据过大的时候速度会变慢（我还因此被扣了个incomplete，虽然我后来才知道可以不用扣的）；据我所知还有一些同学有其他的方法，不过好像在做第三次作业的时候遇到了一些比较难解决的问题。我表达的就是在构建某个模型的时候一定要想想它的实用性和可扩展性，不要为了一时的爽而让自己后来的工作变得麻烦无比。在这次作业中我不幸分到了一个dalao的程序，任凭我怎么找都没找出他的bug，而我自己则被找出了一个开关门边界判断的bug，看来对边界问题的处理上还有待加强。

第三次作业

第三次作业实质上就是在第二次作业的基础之上增加了捎带功能，并且改变了部分输出的规范。假如你第二次作业写得比较中规中矩的话，第三次作业应该会比较容易，但是假如你写得比较非主流的话可能会调整很多地方（我就是因为输入采用了按错误类型同时对所有输入进行几次遍历而不是对每次输入都进行错误判断而犯了错误输出与输入顺序不一致的错）。这次作业主要需要注意的问题就是引入捎带体系所导致的一些新bug，比如同质请求的捎带问题等等，这些问题比较难发现，可以多看讨论区同学们的提问，一般来说对于这类常见的隐蔽问题会有所涉及。在这些的基础之上，第三次作业也变得不是那么难了，应该可以顺利完成。这次作业我同样被发现了一个边界性的bug，即副请求发出时间=主请求发出时间时应该捎带。我也发现了别人的一些bug，比如重复输出（同一条执行结果多次输出，估计是容器的删除操作做的不到位），还有捎带情况下的同质请求处理不当的问题等等。

总结

前三次作业毫无疑问给我们留下了难忘的回忆，但是，这三次作业已经让我们了解到了OO的大概套路。可能在我们上OO之前从一些凌晨三点拍摄的照片中感受到了无尽的恐怖，但是我们现在已经对这门课的大致难度有了认识和体会，虽然不能说习以为常但是至少已经不再陌生。所以说，对于之后的多线程作业，我们只需要按照我们每个人自己总结的方法，同时吸取别人的经验教训，认真踏实地去完成它就可以了。相信大家最后都能在OO这门课上收获到一些宝贵的东西。

 

附上三次作业的分析图和类图：

第一次作业：

 

第二次作业：

第三次作业：