oo第一单元作业总结
2019-03-25 22:07 gzhBuaa 阅读(204) 评论(0) 编辑 收藏 举报oo第一单元的作业以多项式求导为主题,考察处理字符串的一系列操作,涉及正则表达式、集合类等重要知识。递进式的三次作业,使得大家的面向对象编程能力、debug能力、设计与架构能力得到了锻炼,对面向对象编程的思想内涵也有了越来越深刻的理解。
一、第一次作业
1、思路总结
第一次作业的内容是简单多项式的求导,输入的表达式字符串由+或-连接若干项构成。我的思路是对输入字符串进行拆分,以+或-将多项式拆分成多个项。再对每个项进行识别,分析它属于哪一类的项。我设置了一个Poly类,代表每个项,内含求导和输出方法。
2、设计
UML图如下:
由于本次是我第一次正式地进行面向对象编程,相关的经验基本没有,导致我的设计基本上还是面向过程化,类的架构也很不合理。
3、度量分析
方法度量结果如下:
类度量结果如下:
从度量结果可以看出代码圈复杂度较大,方法过长且内容复杂,难以维护与调试。改善方法:合理构造类与方法,明确每个对象,方法的功能应该更加清晰,且每个方法不能过长。并且我的本次作业缺乏面向对象思想,类的继承、抽象类等面向对象常用构造方法都没有涉及。
4、BUG情况
本次作业没有在强测和互测中发现bug。不过在中测时,由于粗心大意,导致我的一个正则表达式中少了一个加号,这让我花费了两天的时间进行了无意义的查找与思索。痛定思痛,以后写代码的时候一定要格外认真,在debug的时候一定要先反复地检查自己的代码,看看是否存在码字上的失误。
二、第二次作业
1、思路总结
本次作业在第一次作业之上有所升级,主要是项中增加了sin(x)、cos(x)两个因子,这在一定程度上增加了分析的复杂程度。但是这并没有带来本质上的难度提升,一些地方可以利用第一次作业的老代码。思路与第一次作业大致相符,需要修改的地方主要是对项的识别,要考虑sin(x)、cos(x)及与其他因子相组合的情况。
2、设计
UML图如下
这次作业的类的架构较上次作业而言有所进步。对于一些特定的功能,如对输入字符串进行空白符合法判断、字符合法判断等操作,我将其从main方法中抽取出来,分别放到一个类中。这使得main方法结构更加清晰,代码可读性也更高。
3、度量分析
方法度量结果如下:
类度量结果如下:
本次作业的代码圈复杂度有所改善,但是仍没有利用继承结构。也许是因为本次作业还不需要用到,但这反映了我面向对象思维还有待继续锻炼。
4、BUG情况
本次作业在强测中发现两个bug,在互测中被成功hack3次。经bug修复后,发现这些bug为同质bug,出现的问题在于优化输出过程中,仅仅简单粗暴地删除所有“1*”子字符串导致输出出现问题。今后在设计中要保持清醒的头脑,考虑地更加细致,思考地更加全面,避免此类问题的发生。
三、第三次作业
1、思路总结
第三次作业在第二次作业的基础上,难度有了很大的提升。主要在于嵌套规则的引入,表达式也可以作为因子出现,这大大增加了设计的难度,对于我来说的确是个不小的挑战。我在本次作业的设计中,主要思路是将类进行嵌套引用,而每个类都内置求导方法,在求导方法中引用其他类:表达式类(多项式函数类)中引用表达式类、乘函数类、三角函数类等,出发点是:表达式是由+、-连接若干项构成,而项分为乘积项(由*连接若干因子)、表达式项(单个表达式因子)、三角函数项(单个三角函数因子)等;乘函数类中引用表达式类、三角函数类等……除了最基础的x和常数,每个类都需要一个识别方法,判断其内部的函数属于哪种类型,于是它们都继承了Identify类,其中包含identify方法。
2、设计
UML图如下:
从图中可以看出一些类继承了公共父类Identify,这有利于整体的结构清晰、减少代码的重复。
3、度量分析
方法度量结果如下:
类度量结果如下:
本次作业代码圈复杂度较低,部分类内聚合度较小。总体而言较前两次作业有所提升,不过还需要在继承与抽象方法上寻求进一步的突破。
4、BUG情况
本次作业并未在强测及互测中发现bug。不过在代码完成后的debug过程中,我前前后后发现了将近20处bug,写代码与debug时间将近1:1。这说明我在将设计转化成代码的过程中,思路并不是很严谨,考虑不够细致周全。或者说在设计的过程中应该更加细致,将每个细节都尽可能地考虑到,不要将思考的压力更多地分配给写代码以及debug的过程中去。