很庆幸我还活着……
千言万语尽在一言中……
好了话不多说直接进入正题，在此对前三次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、首先在心态上：
（1）写代码时的心态：写代码实际是一个比较枯燥的过程，所以这更加要求我们要保持一个心静的状态，尤其是当你一筹莫展不知所措时，沉住气不骄不躁是高效解决问题的最重要前提；
（2）、互测时的心态：拿到他人的代码，找BUG固然是直接目的，但是别忘了这种制度的根本目的是在于在阅读代码互相测试的过程中相互学习，因此仅以钻牛角尖的形式其实并不能让我们有所收获；反过来，当被他们测出BUG时，也要摆正自己的心态，如若确实是存在那样的问题，即使该问题比较***钻，也应该虚心接受，不然怎么叫面向对象呢……
2、关于调试的感想：
（1）、部分同学因为测试不充分导致自己写完了感觉没有任务问题，到了互测阶段就要被挑出BUG，其实根本原因在于你始终站在自己的角度去做测试，做测试时关键在于把自己当作一个客户，你面前这个代码是你需要使用的程序，而你是一个要求非常高非常***钻的使用者，所以你会想尽各种办法找出程序的漏洞，或者通过README发现其说明与程序功能自相矛盾的地方，这样做，相当于你在互测之前已经进行了一次互测，而测试者正是你自己；
（2）、善用调试技巧，不管是输出调试也好，单步调试也罢，调试技巧在测试中显得尤为重要，当你发现一个BUG，但是又不能快速的发现这个BUG具体是由什么造成的，盯着自己的代码发呆则是大忌，是一种事倍功半的做法，此时善于使用合适的调试技巧才是正解；
3、想要写出一个真正面向对象的代码，就必须彻底抛弃面向过程的风格，第一次作业由于难度小代码规格也较小这一点并明显，但是随着要求和代码量的提高，曾经那种面向过程的编程风格注定要被彻底抛弃，最重要的一点在于——减小耦合度，减小耦合度，减小耦合度，你所写的一个类，虽然在程序正常运行时与其他类存在或多或少的关联，但是当撇开系统的功能仅仅阅读这一个类时，它应该可以成为一个几乎完全孤立的示例；
最后感谢给予我们莫大帮助的老师及助教，预祝后程OO之旅一切顺利。
