第一次博客作业

面向对象1-3次作业总结分析

  当在第一次课上了解到要使用java的时候,俺滴内心非常崩溃,但是三次java作业,不到一个月的时间,从一无所知到初窥门径,压力也给了自己动力,从第一次作业的将C语言披上java的外皮,到第二次作业面向“部分”对象的编程,再到第三次作业多继承和接口的使用,让自己也迈入了面向对象编程的大门,自己从“过程”到“对象”的转变还要努力。

三次作业代码分析(设计分析和评价)

 

第一次作业

复杂度分析:

 

由于第一次作业只设计了一个主类所以没有画出类图。

设计分析

  第一次作业是对java语言的初步了解,甚至可以说是不了解,虽然多项式问题比较简单,但是因为时间紧迫,在初步学习了java的基本语法之后,对java类的概念还不了解。所以我的设计过程就是单纯地将C语言翻译成符合java语言的格式,在设计时只设计了一个Main类,所有的属性和方法都集中在里面,用属性代替变量,用方法代替函数,可以说是非常C了。现在回想起来甚至感觉有点好笑……

 

缺点分析:

  对其中的圈复杂度较大的问题进行了探究:

  发现是add方法中在设计运算时判断的条件太多不够简化简介,导致了圈复杂度的增加,而对于main来说,则是因为设计缺陷一开始只是设计了一个类包括了add方法导致的。

课下改进:

  然后自己在反思过程中也对其进行了重新构思设计,将单个多项式作为一个主类,输入单独作为一个类,以及对单个多项式分解后得到的参数组,加法运算,输出都作为一个类来设计然后再进行交互组合。

测试:

虽然自己的设计方法有问题,但是因为逻辑还是正确的所以在评测中没有出现这方面方面的bug。但是因为一开始不清楚try-catch的使用,没有在程序中添加导致出现了crash错误,这点在后面的bug分析中会讲。

 

第二次作业

复杂度分析:

 

程序类图:

设计分析:

  虽然在对面向对象的编程有了初步的理解和构思,但是在看到指导书强制要求实现的几个类的要求时还是有点无所适从,因为不太清楚类之间的组合逻辑以及怎样适当地将几个类进行划分设置不同的属性以及方法。所以花了很长时间去进行构思设计。

缺点分析:

  在针对不同的类设定完成不同的属性以及方法后,在组合的过程中发现设置的属性方法不够全面。导致在最后的运行的类里面出现了许多面向过程式的操作将不同的类串联起来。结构变得十分臃肿。自己也体会到了在对面向对象方法的使用上面还有很多东西需要去理解和学习。在这次的编程过程重点是对调度类的调度逻辑方法的构造,

  对于圈复杂度较大:

 

 

  分析发现是因为要判断输入的请求的错误类型,所以进行的判断较多且相互嵌套,造成复杂度较大

  对于嵌套深度大:

 

 

  由于上面分析的设计问题,导致在main中加入很多组合逻辑来判断串联,导致嵌套深度较大

 测试:

  第二次作业完成过程中学习了try-catch的使用并加入自己的代码来调试和防止出现crash的错误。在公测和互测过程中都没有出现bug。

 

第三次作业

复杂度:

  

类图:

设计分析:

  在第三次作业中,由于学习了继承&接口的使用,指导书给出了必须使用继承和接口并且重写调度类的要求,由于第三次作业的对捎带请求的判断,需要更复杂的调度方法,与之前的调度可以说是完全不同。由于自己的第二次作业的代码没有发现问题,所以第三次作业直接在之前的基础上进行更改,使用继承重写了调度器类,并且对电梯类加以更改。在调度器的设计中使用了与之前不同的方法,即创建一个状态,保存1~10层的按钮是否按下的状态。并根据指令不断改变,这个状态保存的是主请求捎带请求,然后电梯根据按钮状态运行。

缺点分析:

  由于大部分继承了第二次作业的内容,所以也出现了第二次作业出现的问题,即判断指令部分圈复杂度大,组合多,嵌套深度大的问题:

 

  除此之外,自己调度器的调度方法设计的比较复杂也增大了复杂度。

测试:

  由于在截止时间最后几小时通过测试发现了三四处bug,为了及时改正导致结构上的混乱和类的内聚度不够大。但保证了正确性,最后通过公测和互测。

Bug分析

  在三次的公测和互测中,只出现了一个crash的错误,并且十分意想不到。

  这个bug出现在第一次评测的公测中,输入是压力测试,即20个50项的多项式,导致程序崩溃。

  后来分析自己的代码发现程序在进行正则表达式判断的时候出现了错误:这个bug源自于正则匹配需要不断地递归字符串。当字符串递归超过一定长度时间=,就会出现堆栈溢出的情况,使得程序崩溃。深入探究后发现是因为自己的正则表达式太长,导致了深度的嵌套使得程序爆栈。而因为在自己的测试中只测试了20个1项的多项式和1个50项的多项式所以并没有查到这个bug。这个提醒了自己要充分考虑所有的情况,做到真正的完全测试。

 

测试策略——“推己及人”

  在构建测试样例的过程是和自己写代码的过程同时进行,用各个节点的样例测试自己的程序,并且在程序设计过程中对自己解决的问题点对应地创建测试样例。这样在互测阶段基本上已经能够做到大部分的覆盖了。

  同时重视极限样例的测试,在电梯作业中即100条左右的大部分有效的指令,因为小短的测试用例很难发现深层次的难以发现的bug。

  在测试完所有的样例后,再从对方的代码进行分析,查看逻辑结构,和一些自己当时犯错和具有处理技巧的点进行研究,再从可能的错误入手设计新的样例。

 

心得体会:

  1.面向对象编程的优势

  在不断的学习过程中,自己的编程方式也在进行着转变。同时在自己的写Java的时候发现这种方式让代码更容易维护,增加了代码的重复利用效率。由于继承、封装、多态的特性,自然设计出高内聚、低耦合的系统结构,使得系统更灵活、更容易扩展,而且成本较低。

  2.设计规划的重要性

  在每次答疑的过程中,都会出行这样那样的问题,一方面是因为指导书表意不明,另一方面是因为设计者理解不够。所以深入研究设计要求,了解设计目标,十分重要和必要。同时在开始编程之前,详尽具体地进行设计分类十分重要。

  3.代码维护和优化

  在写代码的过程中要注意类的聚合度和类之间的耦合程度,因为自己的代码在这方面十分糟糕所以导致复杂度较高,大大增大了出现错误的几率。要善于使用插件对自己的代码进行分析,时刻关注代码的编码格式规范(codeStyle和CheckStyle)、代码重复、(PMD的CPD)复杂度监控(Metrics)。尽量进行更改优化。

posted @ 2018-04-03 16:55  kkkbaby  阅读(117)  评论(0编辑  收藏  举报