OO第一次博客作业(第一单元总结)

时间:2020-12-28 17:26:56

Q:菜是绿的,鸡是黄的,那菜鸡是什么颜色的?

A:红的,强测全WA了,能不红么。

菜不菜的问题先不说了,认真研究一下这次的题目,以及WA的原因吧。

程序结构简析

三次实验的核心结构都是差不多

第一次的没什么好分析的,每个Item可以用固定的方式表示:num * x ^ n(暂且不考虑格式),然后拼成表达式就行了。

 OO第一次博客作业(第一单元总结)

第二次,以Item为最小单位显然是不现实了,每个Item的项数和项的种类都不确定,那么就用抽象类Factor作为基本单位,常数因子、幂函数因子、sin函数因子和cos函数因子作为该类的具体实现。

每个Item用Arraylist<Factor>实现(不会用Hashmap),每个表达式Expression又用Arraylist<Item>实现。

继承关系很容易看出,由Expression为父类,子类Item,然后是抽象类Factor和实现Factor的四个子类。

OO第一次博客作业(第一单元总结)

所有的类都实现一个求导接口,从最底层的四个Factor实现类写起,Item的求导采用乘法求导公式循环求导,Expression求导采用加法求导公式逐个求导。

简化的方法,就是将每个项变为常数因子*幂因子*sin因子*cos因子的标准形式在进行类似第一次作业的简化。

虽然第二次的重构非常痛苦,但是好处是第三次求导可以特别快速地进行:只须添加一个继承Factor类的表达式因子,修改一下sin函数因子和cos函数因子,就可以实现第三次作业的基本功能了。

由于第三次作业简化要求太复杂就不做简化了。

OO第一次博客作业(第一单元总结)

 

OO第一次博客作业(第一单元总结)

这里只放出最后一次作业的度量结果,从结果上看,还有很大的优化空间,主要是表达式处理上有很粗糙的地方,表达式读入的方式仍旧过于面向过程,写了冗长的函数体。

分析自己程序的BUG


BUG的原因真没什么好分析的,前两次都是在简化的时候发生了对输出的错误处理。但是,两次采用的简化方法并不相同,所以导致BUG的原因也不完全相同。

第一次的简化策略是,逐项输出,以项为最小单位进行简化。在简化中,要考虑常数、幂指数为0、1、-1等的情况。输出表达式时,用+或-进行连接。错误的原因是在常数为0时多输出了一个+号,项却已经被简化没了。

第二次的简化策略仍是以项为最小单位进行简化,但由于此时的最小单位为因子,所以简化起来和第一次相差很大。这次是根据未简化时产生的字符串按正则表达式简化,但由于情况考虑疏忽,导致简化了不该简化的情况,强测出现大量BUG。这就是一个教训:在第一次作业的BUG修复之后,在容易导致BUG的薄弱环节上就不该另起炉灶了

除此之外第二次还有一个地方在拷贝代码时少改了一个变量名,导致求导求错。

第三次的话,就是注意一下评测机系统的System.exit返回值必须为0,不然就会RUNTIME_ERROR就是了。其实在中测的时候就已经发现了这个问题,但是还有一个System.exit(-1)没有改掉,说白了还是自己不细心。

分析自己发现别人程序bug所采用的策略

头两次因为Bug都分在了C组,用黑盒盲测的方法就能发现许多BUG(而且都是一些各种各样无厘头的WRONG FORMAT类问题,技术含量真心低),第三次也无心投入太多时间用来找BUG,所以没什么可谈的。

值得一提的是,有时采用代码评审的方式,能够从代码中直接找出BUG的存在,这个方法在以后处理多线程程序时会起到很重要的作用。

Applying Creational Pattern

如果没错的话应该是用了一个叫什么工厂模式的东西,虽然并不是有意识地在用,写的时候也并不知道这个东西。不过设计模式这个东西真的挺有用的,建议课上多讲一些。