OO前三次做业总结

很庆幸我还活着……

千言万语尽在一言中……

好了话很少说直接进入正题，在此对前三次OO做业作一个简单的总结：

第一次做业：第一次接触面向对象…做为一个没有java编程基础的小白来讲，面对这个原本比较简单的做业仍是比较头疼的，首先不懂java语法，其次不理解面向对象的含义；一脸懵逼……

好在通过两天的煎熬以后也算是勉强入门了，磕磕碰碰写完了第一次做业，因为初次第一次对于面向对象这个概念没有多少理解而且做业难度也不大，因此整个程序只有一个类，代码量110行；主要难点为输入是否合法的判断以及多项式算法的选择，多项式合法性判断采用和了正则表达式，可是一开始使用的正则表达式进行一次判断故没有经过压力测试，第二次将正则表达式判断拆分为两个部分，成功解决了该问题，算法为先将全部项进行合并，而后排序，最后将指数重复项相加，最后顺序输出；

公测：因为阅读指导书不够仔细，忽略了一个多项式指数不能重复的要求，因此公测中指数重复分支错了一个样例；

互测：未被发现BUG，对于本身的测试任务，按照分支树的要求逐一进行测试，并阅读程序代码思考是否存在漏洞，最后并未发现BUG；

 

 

第二次做业：

第二次做业的难点主要在于同质请求的判断，一开始因为对此理解不够准确，采用了直接与前一条请求进行对比的方法，故进行了一次重构改进，按照指导书的要求建立了八个类：elevator , floor , scheduler , commandqueue , command , judge , allcommand , elevatorsystem 。

elevator类：描述电梯的各类行为及属性，包括发送请求，开始执行请求，结束请求，更新电梯状态等；

floor类：描述楼层的行为及属性，主要为上下行按钮，发送请求，结束请求；

scheduler类：进行电梯系统的调度；

command类：包含一条请求的各类属性，好比输入请求的字符串，请求类型，请求楼层，请求时间等；

commandqueue：描述等待执行的请求队列的属性及行为，如队列内请求数量，队首队尾，入队出队；

allcommand：包含全部输入的请求；

judge：包含对输入请求进行各类判断的方法；

elevatorsystem：主类，调用各个类运行电梯系统；

公测：未被发现BUG；

互测：经过阅读测试代码发现其未对主类一些可能发生异常的语句包含在try中，由此发现了一个crash错误；另外发现一条与指导书不符可是README并未作出声明的状况，算做一个BUG。

 

第三次做业：

主要在第二次做业的基础上增长了捎带功能，因为我第二次的设计采用了以电梯及楼层按钮规划电梯行为的方法，故第三次做业并未作出太大的改动，主要的改动为在判断请求是否须要加入请求队列以前先（根据电梯及楼层当前按钮状态）判断该请求是否能够捎带，若不能捎带则进入请求队列，若不能则进入请求队列；另外在电梯类中加了目标楼层及下一个停靠楼层两个属性，并在每次发送请求的时候将这两个属性进行更新；其他都是细节上的微小变更。

公测：未被发现BUG；

互测：并未发现他人BUG；

　　因为README描述不够严谨，关于前零数量被发现一个BUG，未被发现功能性错误；

 

感想：从一个月前几乎一窍不通的小白到如今，三次OO之旅仍是让我很有感触；

一、首先在心态上：

（1）写代码时的心态：写代码实际是一个比较枯燥的过程，因此这更加要求咱们要保持一个心静的状态，尤为是当你束手无策不知所措时，沉住气不骄不躁是高效解决问题的最重要前提；

（2）、互测时的心态：拿到他人的代码，找BUG当然是直接目的，可是别忘了这种制度的根本目的是在于在阅读代码互相测试的过程当中相互学习，所以仅以钻牛角尖的形式其实并不能让咱们有所收获；反过来，当被他们测出BUG时，也要摆正本身的心态，如若确实是存在那样的问题，即便该问题比较刁钻，也应该虚心接受，否则怎么叫面向对象呢……

二、关于调试的感想：

（1）、部分同窗由于测试不充分致使本身写完了感受没有任务问题，到了互测阶段就要被挑出BUG，其实根本缘由在于你始终站在本身的角度去作测试，作测试时关键在于把本身看成一个客户，你面前这个代码是你须要使用的程序，而你是一个要求很是高很是刁钻的使用者，因此你会想尽各类办法找出程序的漏洞，或者经过README发现其说明与程序功能自相矛盾的地方，这样作，至关于你在互测以前已经进行了一次互测，而测试者正是你本身；

（2）、善用调试技巧，不论是输出调试也好，单步调试也罢，调试技巧在测试中显得尤其重要，当你发现一个BUG，可是又不能快速的发现这个BUG具体是由什么形成的，盯着本身的代码发呆则是大忌，是一种事倍功半的作法，此时善于使用合适的调试技巧才是正解；

三、想要写出一个真正面向对象的代码，就必须完全抛弃面向过程的风格，第一次做业因为难度小代码规格也较小这一点并明显，可是随着要求和代码量的提升，曾经那种面向过程的编程风格注定要被完全抛弃，最重要的一点在于——减少耦合度，减少耦合度，减少耦合度，你所写的一个类，虽然在程序正常运行时与其余类存在或多或少的关联，可是当撇开系统的功能仅仅阅读这一个类时，它应该能够成为一个几乎彻底孤立的示例；

最后感谢给予咱们莫大帮助的老师及助教，预祝后程OO之旅一切顺利。