OO第一次博客作业（2018春）
写在前面
虽然OO的大名早有耳闻，但这游戏才第三周，对小caiji玩家也太不友好了，Orz
第一次作业
类图：
第一次作业是多项式的加减法，因为是初识java和oo，所以这次作业我只写了两个类：多项式类（poly）和多项式计算类（poly_compute）。多项式类负责存储多项式以及定义多项式间的运算方法，多项式计算类负责处理输入，分析多项式，调度计算，输出。第一次写面向对象的程序，对于类的划分和方法的运用还不太熟练，写出来的东西还是 面向过程.java，尤其是多项式计算类，代码偏长。
2.度量分析：
从Metric表看，poly_compute类的圈复杂度超标，主要是由于其中的parse_poly方法代码规模有些大，控制分支达24个，最深嵌套4层。几乎从输入之后到计算之前的工作都是由这个方法来完成的。parse_poly方在法分析多项式合法的时候，采用的是正则表达式，为了避免被爆栈（瑟瑟发抖），我用了两个正则，但这样做带来的后果判断的逻辑变得复杂，需要更多的控制分支实现，我又把它们都写在了一个方法里，所以这个方法结构比较复杂。两个类的内聚都不够高，耦合情况还ok。
3.Bug分析：
bug1，输入系数为0时报错。对应代码在 poly_compute类 的pause_poly方法。阅读指导书时把系数为0不输出的规定断章取义地安在了输入头上，所以程序对输入为0的情况也进行了报错。
bug2，重复指数的判断。对应代码在 poly_compute类 的item_fillinf方法。由于上一个bug，相当于我默认未出现的指数的那一项系数为0。在实现判断指数是否重复时，我直接判断了对应指数那项的系数是否为0，若不为0，则说明之前有同类项，指数重复。
第二次作业
1.类图
第二次作业是单部傻瓜电梯，也是第一个自己独立思考完成的java程序。按作业指导书的要求，我封装了5个类：controller（调度器类），elevator（电梯类），request（请求类），request_queue（请求队列类），floor（楼层类）。我在设计时没有用到楼层类；调度器类负责处理输入和调度控制；电梯类有4个属性5个方法，负责更新电梯的运行状态和输出结果；请求类3个属性4个方法，负责记录每个请求的相关数据；请求队列类1个属性6个方法，负责构造请求队列储存请求。这次的作业虽然较上一次更面向对象一点，但还在调度器类main函数里写了大段代码实现输入和调度。
2.调度分析：
依旧是圈复杂度超出标准，这次问题出在了调度器类的main函数里，控制分支有27个，最深嵌套层数3层。从处理输入，分析输入合法，到调度控制电梯的运行，都是main函数实现的，所以造成了主函数结构复杂。这次的程序基本上做到了高内聚低耦合。
3.Bug分析：
第二次作业没有找到（一定是没有发现）bug。
第三次作业
1.类图：
第三次作业是ALS单部电梯，允许捎带，难度陡增，我一度天真地以为在傻瓜电梯代码上改改就行，但现实告诉我得改好多。这次作业的主要工作是写一个调度器类的子类smart_controller，并重写一个可以实现捎带的schedule（）方法。这次作业改正了调出器类只有一个main函数的毛病，在smart_controller里将输入分析、调度控制、报错、同质清除分别封装成了input（）、schedule（）、error（）、erase（）方法。增设了接口ELES，抽象出了这次作业要用到的一些方法，通过电梯类实现这些方法。由于只有一个类（电梯类）用到，所以这个（假）接口在这次作业中没有很明显的作用。
2.度量分析：
作业三中标红的是圈复杂度和嵌套块深度，超标都是发生在smart_controller类的schedule方法中，控制分支有36个，最深嵌套7层，结构相当复杂。在重写schedule时，为了覆盖所有捎带的情况，用了大量的if else 语句控制调度，现在再看，一些控制分支在逻辑上有重合，完全可以整合起来。这次作业的耦合情况还比较低，内聚大体较高，但电梯类有几个方法在写法上是重复的，可以优化。
3.Bug分析：
公测和互测并未发现bug，自测时发现一个bug：在未完成的捎带请求升级成主请求后，捎带了目标是电梯当前层的请求。为了实现能够捎带多条同层请求，我在判断请求楼层和电梯运行楼层时用了≥（≤），漏掉了电梯启动楼层与请求楼层相同的情况。
测试策略
在测试其他同学代码时，我有下面几个步骤：
1.根据分类树构造小测试样例，重点测容易出错的节点
2.用随机生成的大数据样例（来自大佬）测试
3.阅读代码，量身定制bug
一般情况只用小样例和大数据来测试，时间充裕的情况会仔细阅读互测同学的代码。
心得体会
记得刚开学，oo第一次上课，就布置了作业。那会儿的自己啥也不会，小白一个，时间又短（比祭祖还短），简直慌得一批。请教了大佬，研究了学长学姐的代码，速成了java，慌慌张张中也写完了第一次作业。第二三次作业虽然也是拖到了最后才完成，但起码从设计到实现都在有条不紊的进行。
关于互测，有的同学觉得不ok，大家都有发表自己看法的权利，我觉得利大于弊。因为互测涉及到自己的分数，交流时难免有摩擦。我第一次申诉时，对面老哥态度强硬言辞激烈，但一番交流后还是帮我撤了bug。我觉得只要不是碰到恶意找bug的同学，互测还是一件挺有趣的事情。互测机制让我在码代码时更有紧张感，也慢慢锻炼了自己阅读别人代码的能力，这一点在以后的学习工作中也应该是有必要的。
三次作业过后，有几点和大家分享：记得try catch，打死不能crash；仔细仔细仔细阅读指导书（可以把自己认为重要的摘出来）；大致规划（要用到哪几个类，每个类实现什么功能）好再动笔。
革命尚未成功，同志仍需努力~
道阻且长
