OO作业总结

hOmewOrk1 多项式的加减

刚拿到作业的时候，根本不知道怎么写，不知道java怎么输入，不知道及各类之间要怎么互相关联，总之就是各种多项式懵逼。

和大家不同的是，一天我只能速成破产版java，破产版面向对象，对真正的豪华版面向对象还是不甚了解。

把一组数据结构和处理它们的方法组成对象，把相同行为的对象归纳为类，通过类的封装隐藏内部细节，通过继承实现类的特化/泛化，通过多态实现基于对象类型的动态分配。 By 知乎id：Milo Yip （侵删）

然后就硬生生的分成了三类：ComputerPoly, Poly, Judege。简洁的介绍一下：

ComputePoly：

四个方法的功能依次是：

• 解析输入的多项式字符串提取每一个多项式；
• 解析出每一个操作符；
• 调用Poly类的方法进行计算；
• 主方法进行字符串的输入以及调用Judge判断输入的字符串是否合法；

Poly：

三个方法的功能依次是：

• 多项式加操作；
• 多项式见操作；
• 返回计算后的多项式，打印；

Judge：

该类的方法就是为了判断输入的字符串是否合法，合法则返回true，不合法发挥false。

关于测试：

• 最基本的就是先对输入合法性判断进行测试；
• 然后对边界情况进行测试，比如输入的字符串个数超过了界限；
• 第三测试程序会不会因为爆数组等奇奇怪怪的原因而crash，即程序的鲁棒性检查；
• 最后就是阅读理解代码找到可能存在的设计上的缺陷；

以上就是我对第一次作业的简单的理解；

hOmewOrk2&3：电梯

苟活了第一次作业之后，第二次作业对我这种菜菜已经开始有一丝丝的不友好了，我本来对于组织小的部分构成全局的能力就比较弱。于是乎，这对与大伙来说很简单的任务，我又不知道从哪个地方对这部傻傻的电梯开刀。

首先当然是要好好花点时间阅读指导书，我们搞清楚要求是什么，以及怎么实现每一个要求，并把所有的东西串联起来。

我首先将指导书里的要求单独的摘出来，写了一个pdf，如下（第二次部分）：

这的确在后续写代码过程中给了我很大的帮助，我不需要不断的在指导书中挑字眼，挑句子，也不用去issue反复看。

以下是第二次作业的类图，以及之间的依赖关系：

首先我在主类Main里做了输入的指令的合法性判断，并将每一条合法的请求传给Queue类，进行存储，我比较直接地将所有的合法的请求一股脑地全都扔进了Queue类中。Queue类会返回每条请求的类别、目标楼层、方向以及时间。每次调度器类Scheduler都会从Queue类中取出一条请求，由Shceduler类中的scheduler方法，获取Elecator返回的电梯当时的状态，进行同质请求判断，若不同质则将请求传给command类中，再由command类调用Elevator中的方法printState打印每条请求执行后的状态。

作业三的类图及其依赖关系：

增设了主请求类(mainRequest)，以及有点聪明的调度器类(alsScheduler)，继承自原来有点傻调度器类。

有点聪明调度器的作用就是用来处理捎带请求的，然后通知请求还是由有点傻调度器来完成。

主请求类的作用就是用来记录和传递当前主请求的各种属性以及状态，传参数给有点聪明调度器类进行捎带请求的判断。

关于测试策略：

• 同多项式，我们先从输入合法性开始检查；
• 然后考虑边界情况，测试数组会不会存在越界导致程序崩溃的情况etc；
• 然后就可以对拍等手段进行覆盖性测试；
• 如果没有自动测试这样的脚本，我们也可以通过阅读代码主要的逻辑部分，检查其主要逻辑是否分清了主次，分清了优先顺序，是否有重复判断的部分，是否有遗漏的部分。如果有疑似遗漏的部分，我们可以编写针对性测试样例进行检测；

作业三度量分析

• COB: 对象之间的耦合性
• DIT：继承树的深度
• LCOM: Lack of cohesion method（不知道怎么翻译，缺乏凝聚的方法？）
• NOC: 子类的数目
• RFC: Response for class
• WMC: weighted method complexity（方法复杂度）

分析自己程序中的bug

• 空白符未处理，原因就是遗漏了RUN这条语句，没有对它得空白符进行处理，导致出错；

• 没有对代码进行覆盖性检查：遗漏了非法输入时的输出检测，导致有作业二的“ERROR”没有加#或者删除就输出，导致大面积非法输入的错误；

• 没有理清捎带和主请求之间的逻辑关系，以至于遗漏（仍是遗漏）了不少情况；

  对于以上的前两条来说，接下来的作业中要务必认真仔细测试这些不起眼的情况，要严格控制输入和输出；

  对于第三条：首先就是我的类写的比较混乱，类与类之间的依赖关系也没有了然于心，各个属性之间的传递和名称没有做好规划，以至于最后要知道一个参数的意思都要去理解半天。其次就是没有好好研读指导书，以及issue大家提出的种种情况，没有在心里做好整体的规划。搞清楚各个属性之间的逻辑关系，以及规范化变量命名，方法命名，是解决问题的关键。

心得体会

菜菜就不要极限操作了，早点准备早点写完，早点debug。第三次作业的极限操作严重失败，顾此失彼，捉襟见肘，补了这个漏洞出现那个漏洞，最后甚至没有时间检查不合法的输入，我的输出是否正确，以至于我多输出了一行没有标注#的废话，不合法输入检查全错，血亏！

还有一点就是一定要理解指导书里的每一句话，不要没有理解就开始瞎写。最后的极限操作我有时候甚至分不清测试样例里面那些是捎带请求，那些不是捎带请求，连这些都分不清，还怎么写代码？

所以准备工作一定要先做充分。希望今后的欧欧多欧少呕。