BUAA_OO_第一单元总结

BUAA_OO_第一单元总结

1 基于度量分析前三次作业

1.1 第一次作业

  • UML类图

  

  由UML图可以看到第一次作业的程序类图比较简单。只有一个主类,一个Term项类,一个Tool工具类。由于第一次作业相对来说比较简单,对于表达式的每一项都可以化成coef、x、index这三部分,因此我只用了Term类来储存这些内容。这样做的好处是做这一题时比较方便快捷,但可扩展性差,做后面作业每一项的组成更复杂时就不太适用了。

  • 代码行数

  

  第一次作业中各类的代码行数分布较均匀,但主类中代码行数略长。

  • 程序复杂度分析

  可以看到,第一次作业中我的主类,Term中的toString方法,Tool中的getCoef方法的三个指标都全部飘红。究其原因,在写程序的时候面向过程的思想还没纠正过来,导致没有构思好程序就开始写,造成程序个别部分复杂度较高,各部分耦合度也偏高,使做后面作业时的扩展性降低。

1.2 第二次作业

  • UML类图

     

  第二次作业虽然增加了三角函数,但为了图省事我还是沿用的第一次作业的三个类。本质上仍继续采用着面向过程的思想,还不够面向对象,因此相比于第一次作业在Term类内和Tool类内增加了大量的方法以完成程序的功能。这样虽然省了不少麻烦,但也使程序越来越臃肿,遇上新的需求时可扩展性非常地差。(这也造成了我后面在做第三次作业时前两次作业的程序结构基本不能再使用,从而花费大量的时间重构)

  • 代码行数

  第二次作业的代码行数较第一次增长了2倍多,但依然只有三个类,造成程序阅读起来略显臃肿。

  • 程序复杂度分析

  可以看到第二次作业相比于第一次作业飘红的更多了,而且iv(G)和v(G)大大增加了。说明程序的结构没有事先规划好的话,随着需求的增加,程序的耦合度将会越来越高,结构也会越来越复杂,这对一个程序来说是很不利的。从而也注定了在进行第三次作业时这一结构没法继续沿用下去。

1.3 第三次作业

  • UML类图

  由于第三次作业引入了嵌套,复杂度大大提高,因此前两次作业的那种面向过程的方法已经完全不再使用。必须采用更加合理,清晰的结构。因此第三次作业我为表达式中的每一个基本类型都创建了一个类。由所见的类来看,层次更加清晰了,更加符合面向对象这门课所要求的的高内聚低耦合的思想了。

  • 代码行数

    可以看到第三次作业各类的代码行数相对来说还是比较均匀。

  • 程序复杂度分析

  

   

  可以看到第三次作业在对表达式进行处理时仍然存在耦合度较高、结构较复杂的缺点。但其他类和方法的ev(G),iv(G)和v(G)均保持在一个较低的水平,相比于前两次作业程序整体结构要清晰不少,复杂度、耦合度都有不小程序的降低。

2 程序BUG的分析

  由于第一、二次作业都不太难,公测阶段均未出现BUG,但互测阶段均被发现一个同质BUG。第一次作业是因为在某种全部和为0的情况下没有输出,第二次作业是因为对指数大于10000时的WF判断失误,本应该是判断因子的指数,却错误地判断了因子合并后每个项的指数。究其原因而言,前两次过于注重于面向过程,导致程序结构不清晰,从而犯了很简单的错误。

  第三次作业由于花费了大量的时间在重构代码上,导致程序本身出了不小的BUG,使公测结果比较惨烈。其中最重要的一个BUG是没有注意到Arraylist拷贝时是浅拷贝,导致在递归求导删除Arraylist时出了很大的问题,然而却一时却没发现到BUG的根本原因所在。这一惨痛的教训也是前两次作业中不注重程序的可扩展性所埋下的伏笔,造成了不必要的时间在重构代码上。

3 发现别人BUG所采取的策略

  就测试而言大部分同学应该都有手动测试+自动化测试。

  可能是因为我生成的测试数据不太具有针对性,我在使用自动化测试时个人感觉效果不算特别好。因此我其他大部分主要采用手动测试的方法,通过仔细阅读指导书,列出各种覆盖功能性的情况以及容易被忽略的特殊情况进行测试。在自己编写代码时就将自己用过的测试数据记录下来,在互测时就可以用这些代码进行测试。

  另外还可以结合被测试代码的设计结构来进行测试,可以通过UML类图大概了解其代码的结构,从而构思可能漏掉的边界数据进行测试。

4 应用对象创建模式

  就我三次作业的程序而言,由于我的第三次作业有许多的基本类,因此可以在第三次作业运用工厂模式,帮助创建Expression类、Term类、以及5个基本的Factor类,实现工厂模式,这样可以减少创建类时的复杂度,使程序整体更为简洁。

5 对比和心得体会

  通过对比助教所展示的优秀代码,我发现自己整个程序的设计上还存在着不小的问题。首先,优秀代码的结构都很清晰,十分贴切“高内聚低耦合”的思想,而这是我所不足的,在以后的作业中一定要先构思好程序的大概框架再进行代码的编写,不然在作业复杂度提高时相比于这些优秀的代码会做浪费很多不必要的时间来进行重构,使得前后的程序缺少连贯性。其次,优秀代码在性能化简上也做的十分的好,这里面不可避免地涉及许多算法,这也算是我的弱项,因此在以后的学习中要勤于通过网络查询学习,弥补自己的不足。

  这一单元是我真正接触到JAVA的面向对象思想的一单元。众所周知,JAVA最显著的一个特点就是面向对象,回想起大二上也接触过JAVA课,但那时还未能理解面向对象是什么,依稀记得当时的JAVA大作业一main到底,最终主类里有接近一千行,现在再回去读时都读不下去,晕头转向了。由此可见一个好的设计模式、设计方法是多么的重要。这一单元也因为固有的面向过程思维吃了不少的亏,但总算对面向对象有了一个初步的了解和应用。希望在接下来的作业里自己能更加理解面向对象的思维与方法,写出高质量、高可读性的代码。

 

猜你喜欢

转载自www.cnblogs.com/wayxl/p/12535749.html
今日推荐