北航2020OO第一单元博客作业

第一次作业

代码结构分析

UML类图如下:

北航2020OO第一单元博客作业_第1张图片

度量分析:

北航2020OO第一单元博客作业_第2张图片

本次作业我的思路是先去除空格及其他空白字符,然后利用正则表达式读取每一项,再求导并存储在TreeSet中输出。

本次作业我只使用了两个类,主类和项类。可以看到我还停留在面向过程的思维当中,方法的耦合度和复杂度都很高,不利于测试和发现bug。

分析bug

在覆写compareTo方法的过程中,我犯了一个严重的错误。由于TreeSet是由二叉树实现的,所以compareTo函数返回的值会决定当前的元素是放在左子树还是右子树。在compareTo函数中,我用两个元素的指数来比较大小,这样可以保证相同指数的项会被合并。但问题是当指数不同时我选择比较两个项系数的大小(方便让正数项在第一位),这就导致了严重的问题。如果两项指数相同,有可能没法正常合并;如果系数相同,有可能丢失其中一项。

互测中发现bug

互测中我稍微阅读了一下其他同学的代码,发现有同学可能是提前写了之后的作业,但是没有注释掉格式判断的部分,导致输出了WF。

对象创建模式

本次作业我创建对象使用了getItem方法,本质上是先对输入的字符串进行判断(常数还是幂函数),然后直接返回求导的Item对象。但是缺点是复杂度比较高,出现bug很难发现。拓展性也一般,需要加比较多的判断条件。应该采用工厂模式比较好。

心得体会

要知其然还有知其所以然,要不然就有可能出现一些看起来莫名其妙的bug,其实就是自己的理解还不够,不知道一些操作是比较危险的,很容易出现问题。

第二次作业

代码结构分析

UML类图如下:

北航2020OO第一单元博客作业_第3张图片

度量分析:

北航2020OO第一单元博客作业_第4张图片

本次作业我为了方法的简洁性决定放弃拓展性。直接使用数学公式将每一项求导之后用hashMap合并。读入和判断的过程基本与上一次作业思路一致,增加了正则表达式的项。

本次作业的复杂度稍有进步,但还是有特别复杂的方法,需要改进。

分析bug

本次作业中指导书说明了不会因为空格字符的位置导致WF。但我误以为空格字符不会导致WF,所以直接去除了所有的空白字符。在强测中出现了非法字符应该输出WF而我的程序却正常运行了。

互测中我的程序出现了下标越界的异常。原因是我错误的在for循环遍历list的过程中remove了元素,这会导致list的长度变化导致越界。我在网上了解到,正确的方法是应该在使用迭代器遍历时才可以remove元素。

互测中发现bug

我使用了几个我自己出现过bug的数据提交,发现有同学没有对连续的三个符号进行处理,直接抛出了异常。

对象创建模式

本次作业我对对象创建模式进行了优化,尝试使用了工厂模式,并将细节的对象创建另外建立了方法,使用起来比较方便,也很容易添加创建的对象。

心得体会

这次的作业让我认识到仔细阅读指导书的重要性,如果没有清晰明了的掌握了需求,那么就不可能写出令人满意的程序。

第三次作业

代码结构分析

UML类图如下:

北航2020OO第一单元博客作业_第5张图片

度量分析:

北航2020OO第一单元博客作业_第6张图片

本次作业由于要实现递归,所以除了输入处理和判断之外的部分全部重构了。总体思路是将每一种项建立一个类,实现求导方法,最后由一个统一的父类来管理并输出结果。

可以看到某些方法的复杂度还是有些高,但是不会出现特别高的类了。

分析bug

我在本次作业判断WF的方式是如果某一段字符不匹配任何的正则表达式就说明格式错误。但是由于我的疏忽,漏掉了一个空格,导致括号内的空格前如果有数字就报WF形成了bug。

互测中发现bug

经过学习网上其他人的代码,我也搭建了一个微型的评测机,使用评测机找出了同学们一些bug,同学们的问题主要出现在优化和WF上,有些同学多判断了WF,还有的同学优化出现了纰漏,将不该优化的地方优化掉了,导致输出结果出现了括号里什么都没有的情况。

对象创建模式

本次作业在上一次的基础上添加了几个新类就可以正常使用getItem方法了,说明工厂模式的可拓展性比较好。

心得体会

我觉得本次作业难度上确实比较高,这也使我意识到了良好的代码结构会使程序构建和debug事半功倍。

你可能感兴趣的:(北航2020OO第一单元博客作业)