OO第一单元总结

OO第一单元总结

第一次作业

类图

Top-Level Package

代码分析

image-20200321131313347

image-20200321103113502

image-20200321105954500

image-20200321110043235

说明

第一次作业比较简单。我构建了一个抽象类Term,然后由ConstantTerm和PowerFunction分别继承该类,来表示表达式中两种不同的项(常数项和含幂函数的项)。然后由Polynomial类来管理整个表达式。这个过程中我认为我没有把表达式操作和解析表达式分开,因此在Polynomial类中的功能现得比较杂乱,这个是可以改进的地方。可以为解析表达式而专门设计一个类来完成这些功能。而Polynomial类则可以专注于对表达式的操作。

本次作业我使用对象的思想来管理项,但是在表达式解析层面未分离,并且夹带比较多的面向过程式编程导致单个方法复杂。

本人bug

本次作业在公测和互测我方都未发现bug。这个得益于在本地测试的时候可以比较容易的分析出表达式可能出现的情况,同时借助讨论区同学们提供的例子,我方将所有特殊情况都考虑到了。

他人bug

本次作业我读了同room里的所有代码,发现了两个同学的错误,都是在系数为0和指数为0这两种较为特殊的点现错误。

第二次作业

类图

homework2

代码分析

image-20200321131245569

image-20200321112633317

image-20200321125811521

image-20200321130019304

说明

本次作业我建立了Polynomial,Term,Factor三个层次,很好地对多项式进行了管理。同时改进了上次作业的缺点,将解析表达式的功能单独分离出去,单独建立了parse包。但是在性能优化方面我做的不够好,对于优化的方法还是以来这过程式的思想,optimize()方法写的比较复杂混乱,也是容易出现bug的地方。

本人bug

本次作业在强侧中未发现bug,但是由于化简并未覆盖全面,被扣了一点性能分。在互测中果然在优化过程中被发现了bug。本人想将项中的 -1*xxx 优化乘 -xxx,在Term中的print()方法中加入了一下语句

string = string.replaceAll("-1\\*", "-");

由于本人构造的测试集指数大部分为正数,为出现指数为-1的情况,因此未发现自身bug。而在互测中则被发现了 xxx*sin(x)**-1*xxx 的情况,导致我优化后的错误输出。

他人bug

由于此次作业项的类型多,输出比较长,想用构造样例,用肉眼来发现输出bug较为困难。同时代码量相较上次急剧增大,没有足够时间阅读完同room的所有程序。我用自己测试案例进行测试时发现一位同学bug,通过阅读代码后发现,它代码中会在输出2开头的指数时丢失数字2。对于其他同学很难通过手动测试来发现bug,挑选一两份代码阅读也未发现明显错误。因此我着手开始编写自动构造构造测试集,自动评测的程序。在最后几个小时对同room代码进行测试,但是没有发现新的错误。

第三次作业

类图

homework3

代码分析

image-20200321131200718

image-20200321130933192

image-20200321131029863

image-20200321131706133

image-20200321131755174

image-20200321131905711

说明

本次作业难度较大,我构思了好几天才开始着手构造。其中表达式因子是因子和表达式的相互嵌套的关系,因此在解析表达式的时候给我造成了比较大的麻烦。在表达式解析的过程中,我增加了预处理,先将表达式中的表达式因子剥离出来,成为一个新的表达式进行解析,然后一层一层解析进去,生成出一个Poly类的实例。本次作业中还额外增加了空白字符的判断,又复杂了对于解析的工作。好在上次作业的我将表达式拆项,把项拆成因子,这样逐层解析,逻辑较为清晰,本次作业继续沿用这样的思路,因此在表达式解析的过程中并没有出错。但是我将所有解析的方法都放入 Parse类中,而不是像第二次作业按照层次拆成三个类,所以Parse类现得长而复杂,这个是我没有做好的地方。

其次是表达式的管理,我继续沿用上次作业的Polynomial,Term,Factor三个层次,但是由于项中的因子由4种变为不可数,因此我对Term类种的储存因子的方式进行了重构。不过这三个层次的功能还是能很由条理地实现了。

本次作业在优化上并没有要求太高的性能,而且由于项中的因子变复杂,合并同类项的工作也比较困难。我只是简单地判断了两种情况,一种是纯常数,一种是常数和幂函数,对于三角函数我没有做任何化简。另一个是表达式因子的化简,俗称“脱括号”。这个我也只判断了一种最简单的情况,就是表达式因子中只有一个项, 那么我会将这个表达式因子的括号脱掉,把表达式因子中的项,加入到当前的项中。还有一些简单的化简就是将系数为0的项和指数0的因子删去,达到化简表达式的目的。

在优化的问题上,这次代码仍存在着类似上次作业的问题,并未很好得解决。同时由于表达式更加复杂,因此在编写过程中也引入了非常多的bug。平均每进行一种类型的优化就会引入两个新的bug,修复bug的过程也十分痛苦,有浅拷贝引发的bug,也有类似第二次作业字符串化简输出产生的bug。导致我在写优化的过程中花了大量时间在修复bug上。这个是个值得吸取的教训,因为没有一个非常清晰的思路构造化简方法,导致在编写的过程中一直是一种过程式的编程,引入了大量的bug和买下了很多隐患。

本人bug

本次作业我在强测中未发现任何bug,但是在互测中被同学发现了一个bug。我在表达式因子化简的时候,如果表达式因子里的项由于合并同类项都被相消删去,我的表达式因子会为空,而不是0,如果此项不只这一个因子,我的程序仍会为此项求导,以至于输出一个错误的导数。

这个bug的出现还是由于我对表达式优化方法的构造并不是特别合理,还是存在着复杂混乱的缺点,导致考虑并不完全。

他人bug

本次作业代码量大,逻辑关系复杂,阅读他人代码找漏洞的效率较低。我便使用自己编写的自动评测机构造随机样例对同房间的人进行测试。找到了同房间3名其他同学的错误,但是由于没有阅读他人代码,并不是特别清楚他人bug产生的原因。

心得体会

本次作业我都能比较好得完成。面向对象的思想在我的代码里也有体现。在基本功能上,已经达到了课程组的要求。但是在性能优化的进阶部分,我完成的还是不够好,不能够将优化也抽象成类来管理。在阅读了推荐代码之后,我发现可以通过自定义容器和泛型让项和因子的储存更加清楚,这样可以利与化简。这个方法就很好地解决了我优化代码复杂混乱的不足,值得学习。

posted @ 2020-03-21 20:05  MuZiShuiYi  阅读(152)  评论(0编辑  收藏  举报