Loading

2020-面向对象设计与构造-第一单元总结

Part 1 基于度量的分析

第一单元的作业内容是表达式求导,三次作业难度逐次增加。其中本人第二三次作业的结构类似,因此放在一起进行分析

第一次作业

UML图如图


第一次作业项比较简单,可以归结为:仅有由幂函数(带系数和指数)组成的项。其中,为了可拓展性,我把项定义成为了一个接口。输入的解析由Expression类的Constructor和genTerm方法来完成,相关的正则也保存在Expression类中。Expression是一个列表中Term相加组成。求导方法按照求导规则生成新的表达式对象。

但事实上,我的实现效果现在细想来有很大问题,数据也佐证了这一点。

复杂度


先看复杂度,ev,iv,v都是一个方法复杂度不同方面的度量,OCavg和WMC是一个类复杂度的度量。主要的值得警惕的地方(红色)很显然,就在Expression类的genTerm方法中。我在genTerm中使用了层次化构造的大正则,所以处理的代码要面对很多情况,造成了代码的复杂。

事实上,把正则、表达式生成放在Expression类中可以算是一个错误,Expression类明显因此变得过于复杂。

我目前想到的更合理架构是:采用工厂方法,ExpFactory作为一个类专门生成Expression;建立RegexExpression类,专门用来存放正则表达式。

依赖


再看依赖关系,整体来说比较正常,我主要使用了接口,DIT是1.

从数据上看,第一次作业似乎问题只在Expression类上,但事实上,这个设计大有问题,这直接导致我第二周作业全盘推倒重来,几乎成为一个噩梦。

相信大家已经看出来了,幂函数更适合作为一个因子,而不是一个项。此外,还有一个关键的设计问题是,要不要把常数和幂函数分开。从第一次作业的角度来看,这两种方式差异不大,但是从后面的作业来看,分开&保证项里有常数是一个更好的选择,可以省去大量的判断,而且让各自的功能更专一,从后面的代码上看,幂函数是最复杂的一个,所以这样拆开也是一种很好的拆分。此外,保证项里有常数实际是一个很危险的操作,所以我实现时既保证了一定有常数,又预防了没有常数的情况。

DesigniteJava分析


DesigniteJava分析得到的结果是,我最大的bad smell是Unutilized Abstraction,很尴尬,我本来是照着可扩展性强的方向设计的,结果到最后反而是直接推倒重写了

第二、三次作业


UML如图(第三次作业)

看上去可能有点乱,事实上,这是一个表达式-项-因子的递归嵌套结构,因子作为一个接口实现。表达式也实现因子这个接口。这就为套娃留出了足够的空间。

表达式的解析由ExpBuilder这样一个工厂类进行,错误时抛出WrongFormatException省去大量检测。

求导时递归调用,一个Factor求导生成新的Factor List对象。

优化时,optimize方法也是生成新的对象,而涉及到合并的操作则在添加项的同时完成。

为了节省时间,添加了isOptimized标志来避免在建立表达式的过程中对没有变化的项做无用的优化,forceUnsetOptiflag方法来清除这个标志位以便于进行彻底的优化。

在第三次作业中,添加了furtherCombine相关的方法来进一步减少长度捞性能分(虽然最后关头还是为了避免bug回滚了(而且回滚后还是有点小bug(悲。

当然,这个架构还有很多可进步的点,最大的问题就是Term,Term项上下都要依赖,严重提高了程序的复杂度和Bug出现的可能性。

此外,细心的读者可能已经注意到,这里我因子的操作方式是类似字符串这种不可变对象的,但是Expression和Term都是可以动态变化的(添加新的项/因子),目前我的做法是,在将某个因子构建完成、或加入一个容器之后,就再也不改变他,以防因为浅拷贝出现的各种问题。但这种需要“额外知识”才能更改代码的做法显然降低了软件的可维护性。

行数(第三次)

可以看到,这次作业规模不小,最多的代码在Term上(部分原因是Term有两套合并同类项算法),然后是Expression,ExpBuilder,除表达式外因子中幂函数的代码最为复杂,这很好的说明了拆开幂函数和常数的必要性

复杂度

二/三次作业复杂度只能用爆炸形容,如图(以下均为第三次内容,第二次->第三次我仅更改了读入部分和加入了一定优化)

复杂度最大的是ExpBuilder,仔细想了一想,应该是getFactor的锅,为了方便我把对所有因子的解析放在了一个方法getFactor里,实际上完全可以把不同的因子分开设置一个方法来处理。复杂度分析证实了我的想法。

再接下来复杂度较大的就是Term类了,无论第二次还是第三次作业,Term都既要与Expression打交道,又要与Factor打交道,同时承担了最多的化简任务,可以说设计的着实不太好。


Term的复杂度主要表现在:优化合并(第二次三角,第三次带括号)和输出上,这也是程序的设计难度。

Expression类,复杂度也集中在化简和添加项上



依赖


依赖关系仍然整体来说比较正常,我主要使用了接口,DIT是1.正是因为使用了接口,才尽量减少了Cylic型依赖

DesigniteJava分析

DesigniteJava检测得到,Design smell最严重的还是Unutilized Abstraction,的确,我这个架构在最开始的时候还考虑了幂函数的嵌套等问题;但此外还有Insufficient Modularizatio问题,在Expression和Term中,这证实了我的想法,这两个类应该进一步重新规划。

Implemention smell中10个Complex Method,5个Complex Conditional(溜,主要还是上面说的Expression和Term里。还有几个Magic Number,但是这些所谓“魔数”其实只是求导和优化产生的数学结果,所以我认为并不重要。

Avg LOCC 128.3,还是比较大的,Avg LOCM只有10.03,倒也不算太大。

架构分析与重构思路

基于上面的数据,我们不难看出,问题的核心是Expression和Term这两个类,特别是Term,整个体系中只有它不能用Factor接口调用。

自然的,我的想法就是,让项也成为一个因子!但是这样一来,完美的嵌套结构就会出一点问题。考虑到其实,存在只有一个项的表达式,我们不妨改变一下递归定义。

Expression的特征是由项加起来构成的,考虑到有的项只有一个因子,我们现在又计划把项作为因子,不妨把他的定义改为,因子相加的产物,同时还实现因子接口。将其称作AddItem。

类似的,把Term的定义改为因子相乘的产物,同时还实现因子接口。将其称作MulItem。这样可以极大地简化编码和不必要的嵌套。

对于嵌套,可以继续沿用基本因子内置负荷构成的方法。

Part 2 程序Bug分析

在第一、二次作业中,我的程序在强测、互测和自己的测试中均未发现Bug,原因可能是我在提交前都用了自己设计的评测机进行了大量测试,以及设计时的小规模验证(有点TDD的意思了)。

第三次作业在强测、互测中仍未发现Bug ,然而事实上在本人后来的自测中发现还是存在两个Bug。(谢各位大佬手下留情(溜

  • Expression类和Term类的equals方法重写时出错,导致使用indexOf时得到错误结果,引发Bug
  • 合并同类项时,未考虑一个项中存在多个相同因子的情况,导致出错

触发条件:项的因子数相同,但是因子会重复出现,且重复出现的次数不同,就有可能在合并同类项时触发。

样例:

(x+1)*(x+1)*(x+2)+(x+2)*(x+2)*(x+1)

x*(x+1)+x*(x+1)*(x+1)+x*(x+1)

总的来说,这两个错误都是在Expression和Term这两个最复杂的类里。其次,错误来源于在程序设计阶段时,我默认会把一项中所有的相同因子合并,这样就不会出现问题。但是在第二次作业到第三次作业的迭代中,这个“隐藏约定”被打破了,因为幂函数不能嵌套。

总结出的一点规律就是,尽量不要在程序中存在“隐藏约定”,这样很容易在迭代开发中出错。而且就算加以注释,其实也没有很合适的地方。

Part 3 发现他人程序Bug所采用的策略

  • 直接上评测机跑(溜
  • 看见Bug能修就修修完继续跑(加速溜
  • 第一次作业:关注正则,看是否会有误判,关注特殊情况下的输出
  • 第二次作业:除第一次外,额外关注优化和投机取巧(某位同学投机没注意到long范围和负数限制被当场爆破)
  • 第三次作业:除前两次外,关注同类项合并以及优化带来的错误(就是自己的错),还有优化带来的格式错误(cos()(1+x)*(1+x)把括号给去了导致错误)等。

Part 4 应用对象创建模式

基本在第一部分的时候已经分析过具体的重构方法了,此外:

  • 首先,使用工厂方法,创建表达式时,注意工厂方法内部的拆分
  • Expression和Term分别用AddItem和MulItem代替,形成一种多叉树的结构
  • 合并时采用迭代器模式
  • 尽量使用Clone避免浅拷贝问题

Part 5 对比与心得体会

  1. 不要在不该拓展的时候瞎拓展,留出拓展空间固然重要,也不要过于复杂化问题
  2. 千万不要有“隐藏约定”,Bug最容易在这里出现
  3. 代码不能太过复杂,该拆则拆
  4. 当你连注释都不知道写在哪合适的时候,就该思考自己的设计是否合理了

OO第一单元总体还是比较平稳,个人最艰难的时候是第二周试图一步到位。其实一开始就设计好的架构并不一定是最好的,在开发的过程中可能就有更好的方法出现。所以如何迭代开发,在可拓展和过度复杂化问题间找到一个平衡,这是我下一步要努力的方向。

posted @ 2020-03-19 16:39  VOIDMalkuth  阅读(250)  评论(2编辑  收藏  举报