oo第一单元总结

OO前三次做业总结

第一次做业

设计思路

Term做为一个项，包含系数、指数。

Poly为一个多项式，内部有ArrayList<Term>，方法包括排序、合并同类项、求导、输出等。

代码分析

指标含义

ev(G)：基本复杂度（Essential Complexity），此指标是用来衡量程序非结构化程度的，非结构成分下降了程序的质量，增长了代码的维护难度，使程序难以理解。所以，基本复杂度高意味着非结构化程度高，难以模块化和维护。实际上，消除一个错误有时会引发其余的错误。

Iv(G)：模块设计复杂度（Module Design Complexity），此指标是用来衡量模块断定结构，即模块和其它模块的调用关系。软件模块设计复杂度高意味着模块耦合度高，这将致使模块难于隔离、维护和复用。模块设计复杂度是从模块流程图中移去那些不包含调用子模块的断定和循环结构后得出的圈复杂度，所以模块设计复杂度不能大于圈复杂度，一般使远小于圈复杂度。

 v(G)：是用来衡量一个模块断定结构的复杂程度，数量上表现为独立路径的条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，经验代表，程序的可能错误和高的圈复杂度有着很大关系。

以上指标含义来自http://www.javashuo.com/article/p-hrljazti-hd.html

经过上面的指标能够看到Term.getCoefficient(String)方法的基本复杂度较高，程序结构化程度不够。

Poly.printCoefficient(Term)和Poly.printIndex(Term)两个方法的模块设计复杂度和模块判断结构复杂度较高。关于输出部分的设计思路：Poly.print()方法进行输出的时候，首先输出系数，同时在其中判断指数（关于指数为零的优化），而后输出指数，此中判断系数，同时根据指数判断是否输出x。这部分的设计比较复杂，耦合度也较高，须要改进方法进行优化。

公测

在输出指数时没有判断系数是否为0，因此会输出*x^-30这种结果。

优化方面,没有考虑到正向提早在某些状况下可使输出的长度变短。

互测

被hack：

(1） 同公测bug

(2） 一种WF，即连续常数相乘，如-12x会输出求导结果，没法判断 其为Wrong Format！

hack：

主要关注WF的问题，方法也主要使经过分析其正则表达式。（第一次做业读完了同room的7份代码，虽然能够比较全面地发现问题，可是比较累。）

总结反思

第一次oo做业中出现的问题总结以下：

（1）结构化设计的思想没有很好地实践，在写程序地过程当中还有面向过程的思惟。

（2）最开始采用大正则，没有考虑到爆栈的问题，修改成用小的正则表达式进行获取阶段后解决。

 

第二次做业

设计思路

Term做为一个因子，包含系数，x的指数，sin(x)的指数，cos(x)的指数。

Poly做为一个多项式，内部包含ArrayList<Term>，相比于第一次做业，在输出方法和求导方法进行了补充，增长了正项提早方法(advance)和sin(x)^2+cos(x)^2=1的化简方法。

代码分析

公测

在公测中没有Wrong Answer的测试点。

关于性能：实现了正项提早和sin(x)^2+cos(x)^2=1的优化，可是合并同类项出现了问题在第一次做业中合并同类项时采用的是先按照x的指数升序排序，而后进行合并，在第二次做业中想采用和第一次做业相同的思路，可是仅对x的系数进行排序，致使x指数相同时，不能实现对sin(x)和cos(x)的排序。因此性能分......

互测

被hack：0

hack：0

总结反思

二次做业偷偷懒，三次做业火葬场。

 

第三次做业

设计思路

基本项：Constant、x、sin(x)、cos(x)

组合项：加法项（Add）、乘法项（Multiply）、嵌套项（Sinnest、Cosnest）

按照加法项、乘法项、嵌套项初级拆分表达式，最终获得基本项，整个表达式呈树状结构，递归求导和输出。

代码分析

 

Bug修复

由于第三次做业在表达式的处理上出现了严重的问题，致使公测和互测同时炸掉，因此两部份内容合并为bug修复进行总结。

这次做业表达式的分解和存储所有经过寻找每种组合类型的特征来完成，如加法项经过识别括号以外的+-号来判别，乘法项经过识别括号以外的*来判别，须要考虑到某些特殊的状况，如（x+x）没有括号外的正负号，但倒是加项、-(sin(x))存在括号外的正负号，但倒是嵌套项，主要问题出在整个表达式的外面嵌套了能够去掉的括号，须要经过判断开头和结尾的括号是不是一组进行去括号处理，同时要注意括号外的正负号问题。

sin和cos的嵌套项经过正则表达式来完成，可是须要注意的是，若是嵌套的部分是个表达式因子须要加括号，不然为Wrong Format，不论是否是表达式因子，在建立新的对象时都须要进行去括号处理，尤为嵌套因子是基本项地时候，去括号问题很容易被忽略，程序可能会出现 RUNTIME_ERROR 如sin((0))。

hack：构造特殊的输入数据，如上所述对同room代码进行测试，互测过程当中发现了不少本身的bug（暗暗后悔）。

反思总结

关于化简问题，架构问题使得化简变得复杂，须要考虑的状况不少，最终放弃了化简，深入认识到了架构的重要性。

关于表达式处理问题，在上部分bug修复中已经对出现的问题作出了总结，以后在写程序的过程当中，会尽可能全面地考虑输入可能出现地状况。