OO第四次作业

OO第四次作业

作业1 多项式运算

oo度量

类图

程序很简单明了，所以各个指标也还算符合要求。（当然...还不够好）

bug反思

自己的程序未被同学找出bug，但readme书写的并不完善，没有对所有可能出现的情况做出说明。匹配到的同学程序输入采用的是状态机，忽略了一些输入导致的异常。（由于我也是用的状态机所以对于可能出现的bug格外熟悉）
第一次作业结束后我自学了正则表达式，体会到了这货的方便之处，为以后减少了很多输入上的复杂性。

作业2 傻瓜电梯

oo度量

圈复杂多过高，类的设计不够合理

类图

其实light类的子类完全是在当结构体用
程序很简单，

bug反思

自己的程序在公测中出现了一个bug。在判断指令时序时，我只判断了FR，而没判断ER。与其说是疏忽，我更愿意把错误归结于程序书写策略。因为在判断时间时ER,FR的行为完全一致，程序中，这样相同的工作应该只出现一次，而不是被反复书写。匹配到的同学没有bug，很优秀！

作业3 ALS电梯

oo度量

圈复杂多过高，类的设计不够合理

类图

Scheduler类有些繁琐了

bug反思

我和我匹配到的同学的程序中都未发现bug。我们真棒!

bug分析策略

在构建测试集的时候，我会按课上给出的分支树遍历自己程序的各个功能，并单独测试一些特殊情况；除此之外，构造压力测试，极限数据，也必不可少。
在做完这些后，我们也可以利用脚本生成一些大量而随机的输入，运行出结果后与同学做对比（我使用了Windows下自带的fc功能），从而根据程序行为找到bug。

心得体会

不急于编码

想起来去年计组时高老板说的"写代码前先思考，不要急于编码，要追求加速式回报"。想来这对OO也是很有帮助的，在写程序前，我们应先思考程序的目标是什么，为此我们应该用什么数据结构来维护数据，用什么算法来实现功能。有了思路之后，再对自己的程序编码，测试，这能大大减少不必要的修改。

设计合理的类

想必各位听过"God Class"和"Idiot Class"那个笑话了，实话说，我在前三次作业中出现了很多这样的情况，有些类定义了一堆数据和方法却没用过，有些类实现了太多功能，回头看来颇是搞笑。比如第二次作业的Floor类

public class Floor{
	public int[] f;
	public Request FR(Request FloorRequest,ReqQueue Q){
		Q.receive(FloorRequest);
	}
}

这个解析FR指令的功能我原想在Floor类中实现，编码编到一半就忘了...然后就出现了一个傻瓜类（"Idiot Class"） = =| | |