面向对象第一单元训练总结
这一单元总体训练我们的java编程能力基础，和对面向对象概念的初步认识。在一开始并没有任何java基础的时候，可能觉得连输入输出都是问题。但是当渐渐熟练java的时候，当略微理解“万物皆对象”的思想后，当感受到OO封装效果的时候，觉得java语言真是很好的面向对象语言。
第一次作业:多项式加减
我第一次写多项式的时候，是先用C语言写了一个类似于词法分析的处理函数。在调试基本实现功能的时候粘贴到java工程的一个public方法里，然后在Main函数中输入后调用了下了事。后来在逐步学习中也学会了使用正则表达式匹配字符串，学会了在Main里处理输入，学会了构建多个类：项、多项式。
上图中分析了第一次作业的度量。第一次使用Metrics插件，不是很了解各项指标的含义；但是还是可以简单看出第一次作业一共写了166行代码、3个类、2个静态方法（其中一个是Main函数）、总共13个方法、4个属性等等。
这是第一次作业的类图，可以看出很好的体现了面向对象编程的思想。各个类主要的工作也很明确。不过当时完成作业时不够严谨，Scanner对象没有close。而且我不太会使用eclipse进行debug。好在第一次作业没什么错误，测试任务是个大神我也没找到什么问题。找bug的思路是按照老师ppt所给的分支树来走的。
第二次作业:FoolSchedule电梯
这次的作业难度也是不大。识别输入的指令然后执行，然后输出相应的结果。对于输入处理，用正则判断格式后使用String.split()方法拆分字符串，然后对指令的各项数据进行分析。最后输出电梯状态即可。可惜我本次作业在处理输出的时候少了一对小括号结果公测全错。
从度量表中可以看出，这次作业我的Main函数里嵌套块深度和循环复杂度都比较高。因为我在Main函数里写了个双重while循环，外层用来处理Scanner的多行输入，里层用于过滤第一个时间为0的请求前的无效请求。这次作业一共有188行代码、6个类（不知道为啥表中是7，显示Lift类里有2个，但似乎并没有）、13个方法、15个属性。
其中Floor类并没有太多功能，其他部分的具体功能俱已实现。但是由于输出格式的问题导致了这一次的无效作业，所以没能参与互测。而我自己的代码，忽略输出格式错误后没有什么bug。
第三次作业:AlsSchedule电梯
第三次作业继承于第二次作业，但是其调度方式有所改变。添加了捎带的功能，使得电梯运行的过程更加的复杂。如果是按照过程式编程的方法会因为请求队列的动态变化而不断的调用修改队列的方法，而面向对象编程时把维护队列的工作交给具体的类处理。虽然如此我这次作业中还是有大堆代码用于维护队列和查询同质请求。如果说前两次作业是面向对象的入门级难度的话，那么第三次作业可以说是进阶了。对于需求分析的不足和类的设计不全面，强行按照指导书的要求写的类并不能我明白每个类具体的工作。说到底，面向对象编程的核心思想是一切方法归于对象，外界只需要观察对象的状态而不需要过多了解对象的内部机制。但这就要求我们良好的分析对象的任务和其应有的功能，同时能够清楚对象之间的交互需求和必需的接口方法。
这次的作业，同样的嵌套块深度和循环复杂度比较高，是因为我囿于固定思维在ALS_Schedule类里写了多重循环来进行请求队列的维护。而电梯、请求、请求队列类里的功能太少。究其原因，还是因为分析不到位。对于类的功能有一定的误解。
这一次的代码虽然不是很符合面向对象的思想，但是基本功能还是没有问题的。公测就错了一个点，是因为少写一句判断而把捎带请求提前输出了。互测没有什么bug，许测我的同学懒得找吧。我测的代码问题还是有的。首先就是他只有一个工程文件，没有实现interface。其实我个人角度是很不喜欢只写一个文件的，虽然不是不可以只写一个.java，但是我觉得这样有可能搞混逻辑（虽然我多个文件逻辑依然不是很清楚）。其实是他对于指导书要求的需求范围实现的不够，一些边界测试就过不了。功能方面倒是没有什么大错，也许只是个人习惯的一些纰漏。我测试是是按照老师ppt上的分支树一点一点测的，但是讲真因为捎带影响次序而对这次的测试数据的产生有很大的影响，构建测试样例时总要多考虑捎带后的结果。我个人大脑思维可能是过程式的，所以对于面向对象程序的运行考虑不周，不知道以后多线程的程序又该如何测试呢。
心得体会
通过这几次基础的作业我觉得java不是一门很难的语言，面向对象编程的思想也不是那么的高深莫测遥不可及。但是OO课程作业难度我觉得是指数增长甚至可能是跳跃式的，这三次作业就算没有任何java基础，总还是可以完成的，与之后的多线程作业相比，无疑是简单太多了。如果对面向对象的理解不到位，我觉得可能在多线程的复杂结果前陷入困境。只有更多的学习，更多的练习可能才会有更好点的结果吧。（话说多线程会莫名其妙导致结果不可重现吗？）
