- 第一次作业
类说明
在第一次作业中，我一共使用了两个类，一个是public class PolyCal，另一个是class Term
Term类主要是定义了一个对象Term，也就是多项式中每一个项，包括有两个属性，还包括其带有两个参数的构造方法public Term(int c, int n) ，计算项的相加方法public Term add(Term p,Term t)，相减方法public Term sub(Term p,Term t)这个类一共占了20行。
PolyCal类主要定义了一个用于计算多项式加减的对象，还包括从标准输入读入字符串并且对字符串进行处理的方法getTerm。其中字符串处理的方法 运用了七个控制分支，对读入的一行进行遍历，每读入一个字符就将其分类。运用控制分支排除不合法的输入后，将合法的输入转换为一个Term类。使用ArrayList将这些项整合在一起；另一个方法是sortPrint，将ArrayList中的不同元素从那个小到大进行排序，相同元素系数相加，最后输出ArrayList中的内容。
发现的bug
在公测和中我错的类型分为两种，一种是没有正确理解指导书，一种是在字符串的合法检查中出现的错误。
对于第一种错误，主要是因为第一次根据指导书进行编程，对于在指导书中的一些要求产生了不正确的理解。比如指导书上规定了输入系数和指数的范围，我以为这个规定等价于输入必须遵循这个范围，即不会有超过这个范围的输入。还有一个多项式内不应有两个指数一样的项，我也在理解上出现了偏差。于是对于这些方面都没有进行容错处理。
对于第二种错误，主要是因为在检查字符串是否合法时我用了括号匹配这种方法，这个方法在字符串字符排布比较规律的时候很有用，但在这道题里出现的字符和组合方式很多，这就导致越写越下不下去，因为非常的繁琐，所以很多情况没有考虑到，在公测和互测中都被查了出来。
测试bug的方法
考虑很多字符串的组合，边界数据，以及特殊情况进行测试，避免与公测集重复
优缺点
优点：在合法的输入时很简单的将字符串处理成了一个项。
缺点：类之间分配不均衡，因为第一次面向对象编程，思维还是面向过程式的，所以那个Term类并没有起到太大的作用，基本所有的方法都是在PolyCal类里。属性之间的调用也十分不规范；检查字符串是否合法时用了十分麻烦的方法，应该用正则表达式匹配或者字符自动机。
类图
第二次作业
类说明
这次作业按照作业指导书的要求，定义了五个类，分别是floor：代表楼层
Elevator代表电梯，scheduler代表调度器，request代表请求和requestQueue类代表请求队列。
在floor类中定义了sendFloorRequest方法，用于发送一个来自楼层的请求；elevator类中定义了sendEleRequest方法，用于发送一个来自电梯内部的请求，Request类记录一个请求的类型，目的地和发出的时间，这些请求都储存在queue中，本来的设想是像第一次作业一样使用ArrayList，但是考虑到队列的实现还是用数组比较习惯，就还是选择了一个Request类型的数组。
对于调度器的实现，这次选用了字符自动机来检测不合法的输入。虽然代码量也比较大，但是好处就是思维量少，自动机写出来后很直白易懂，出了bug也很好维护；这次还使用了try-catch来处理各种异常情况，少用了if控制分支来判断，代码更加美观易读。
刚开始写的版本是按照有效请求组成的队列进行检索。一次循环处理一个请求，即每一次循环后电梯都已经执行了一个请求，到达了目标楼层和到达的时间。可是这样的一个问题就是难以判断同质请求，因为不知道电梯运行的中间过程。在我反复思索后，我不按照请求的队列进行检索，而是通过时间序列进行检索，每一次循环时间增加0.5秒，每一个请求的出现具体化为电梯按钮的亮暗，相当于如果在一个电梯按钮还亮着的时候，再按这个按钮肯定是不会再有变化的，这样就可以轻松地判断出请求是否同质。
发现的bug
在公测中我有两处错误，都是在运用自动机检测不合法表达时不够熟练导致的。后来的改正有两点：在用自动机检测的最后应该return false；若已经匹配到了合法的字符串，还应该判断是否已经检测完字符串的所有字符。这两点应该格外注意。其他的设计暂时没有发现什么问题，互测也没有什么问题。
测试的方法
与第一次的测试思路一致，对于公测已经进行的功能测试进行强测，并且继续进行边界数据（大于四字节的时间）进行测试。
优缺点
优点：使用字符自动机，try-catch这些特定写法或者算法，使程序更加容易维护，bug也显著减少。
缺点：与第一次问题相同，类之间分工不均衡。Floor类和Elevator类实际上并没有什么真正的作用。。。后面记录电梯的状态也是用一些int型的变量来记录电梯当前的楼层。总的来说还是一种面向过程编程（虽然在我个人看来现在的程序还体现不出面向对象编程的优势，利用面向过程编程也一样可以应付得来）。
类图
第三次作业
类说明
第三次作业总体上来说在类的使用上与第二次的类似，在这里就不再赘述了。
在对输入字符串合法性的检查方面在第二次作业的基础上进行了升级，改正了上一次电梯中出现的问题。
设计了继承原来调度器的新调度器，新调度器增加了捎带功能，说是继承但是基本上是重写了方法。由于我按时间顺序对队列进行检索，在判断同质请求这一方面没有问题，但是这样就导致对于捎带条件的判断出现了比较大的困难，而且对于需要STILL的电梯的状态判断比较麻烦，但是也没有办法，只能硬着头皮写下去，最后到周二的晚上熬夜才完成了整个代码的构建（不包括debug）。
发现的bug
在输出时犯了一个非常愚蠢的错误，由于没有看清指导书，把INVALID和request之间加了一个反斜杠，导致公测错了十个点。其他方面的设计都暂时没有发现问题。
测试bug的方法
在前两次测试的基础上我注意到要结合readme进行测试，对于一些readme中表述不清楚的地方很有可能就是开发者不清楚或者有微小bug的地方。
优缺点
优点：没什么优点，写代码越来越熟练可以算吗。。。
缺点：竟然没有看清作业指导书，这真是致命的错误，不过反过来一想也是一件好事，这次只是没有看清无效输出的格式，没有所有点都挂掉，算是吃一堑长一智，以后的设计中一定不能在这些基本的方面出错。而且并没有用到interface（会用但是实在不知道怎么用在程序中。。。），还是没有对继承和多态有很深的理解。
类图
心得与体会
经过这三次作业的洗礼，我发现其实机组跟oo比起来还能好一点。。。以前从来没有进行过工程开发，这几次作业也算是小小的领教到了这种指导书特长，要求特别多，对于所有情况都要考虑进去的感觉。感觉对面向对象的体会也越来越深刻，面向对象变成所体现出的结构上的优越性也在逐渐显露出来。万事开头难，我认为这三次作业出现的不好的编程习惯、不规范的写法和不整齐的代码结构也不完全是坏事，能从中吸取教训并且争取在之后的作业中改正就是好事，也算是写这篇博客的意义所在吧~