BUAAOO 第一单元

一、基于度量分析

0. 度量指标

• CSA: 类的属性个数
• LOC：类的代码行数
• CSO：类的方法个数
• CONTORL:控制分支数目
• LCOM：基于相关联的方法的个数表征类的内聚
• CBO：计算相互耦合的类的个数
• v(G): 方法的圈复杂度，判断模块的复杂度
• ev(G): 方法的基本圈复杂度，衡量程序的非结构化程度
• OCavg：类中方法的平均圈复杂度

1. 第一次作业分析

1.1 类图

1.2 类的设计

• PreSymble：用来预处理表达式里的空白符和多个符号同时出现的情况，主要是为了让符号直接纳入系数里，项与项之间便可直接认为是以加号相连。

• GetPoly：用于从表达式里分割出项，并且将项分为若干个因子，存入列表中。主要是为了解析并存储整个表达式

• Deriv：对每个因子进行求导，并且返回求导结果

• Combine：用于多项式同类项合并

• Least：作为因子的类，里面设计有输出函数（优化的地方）

• Poly：作为项的类。

1.3 类的度量分析

经过分析可以看到，combine和main的复杂度较高，因为我在main里一共进行了好几次独立操作，比如在项里遍历因子求导，但实际上这个操作应该放在poly里更为合适。combine里我先采用了treemap进行合并同类项，最后又把treemap遍历存入List当中，其实整个就可以直接只使用treemap。

1.4 类设置的优缺点

• 优点：将解析表达式、求导、合并同类项等操作封装成类，比较清晰
• 缺点：不该设置preSymble，因为不符合题目所给意思。同时对题目的结构没有把握清楚，划分过于简单。

2. 第二、三次作业

因为我从第二次作业就开始重构了，第三次作业主要是基于第二次作业，加入了少部分格式判断，所以放在一起分析，以第三次作业为分析主体。

2.1 类图

2.2 类的设计

• main：负责调用解析和求导方法
• Factor：因子的父类，包含主要的三个方法：解析因子、对因子求导、输出因子内容
• Cons：常数类，继承了factor
• Expr：表达式因子，继承了factor，但是在解析的时候，会使用方法matchBracket将括号整体直接替换（为了实现正则），使用setSig来判断项是否具有正负号
• Sin/Cos：三角函数，重写了求导方式等
• Pow：幂函数类型
• Item：项，继承了factor，重写了factor里主要的三个方法。
• presymble：用于清除输出结果里的多个符号，将多个符号化为1个
• Check：用于检查格式是否合格

2.3 类的度量分析

通过分析可以看到，之后的作业显然变得臃肿了起来。以sin为例，里面装了20行的正则匹配式子，而正则匹配的式子大可以放在一个类里面，封装为match类。同时decode方法里还包含了众多小操作：比如提取/判断sin系数，判断sin的指数等，这些都可以单独再封装进方法里。代码不够简洁，重复代码太多是这次臃肿的主要原因。

2.4 类设置的优缺点

• 优点：将factor、item、expr分成了三个类，也符合了题目划分的意思。将decode、print、derive方法都放入这三个类，符合数据的特性。
• 缺点：不应该将表达式因子和表达式混为一类，虽然只是一层括号的区别，但是始终不属于同种数据，思路不够清晰。

二、程序Bug

1. 第一次作业

强测通过，互测被Hack一个点。因为最初将coe设置为bigdemical，所以在转换的时候用了一个int型的Temp来转换类型，最后导致数据溢出。这个错误对代码行等的复杂度没有影响。这个错误只要我稍微用过大数来测验就不会犯错，但由于摸鱼了所以没对自己进行测试，所以这个问题是完全可以用数据来检查的。

2. 第二次作业

强测挂了部分点，互测被hack若干次（头被打爆）。虽然第二次重构了代码，但是仍然受到第一次的束缚，没有按照文档中的格式来书写正则，导致漏掉表达式因子也可能具有符号这一特点。所以在修复bug中，只能在表达式类提前判断是否具有符号。修复过程中代码改动量不大，但是明显可以感受到整个思路的错误走向，表达式符号只是冰山一角。

3. 第三次作业

强测还是挂了一个点，互测被hack了一次。错误原因是来自于格式判断，误将一个正确表达式判断成了错误，没有考虑到首项出现x的情况。修复的时候只修改了check的一个标准即可，代码复杂度无变化。

三、Hack别人策略

1. 第一次作业

第一次作业比较简单，主要错点就是大数处理和求导。所以只需要构造一次大数据检验大数处理是否合格，之后设定比较小的数据（最好是重复）来进行检验求导问题。

2. 第二、三次作业

这两次作业我都没有主动hack别人（因为懒得搭建评测机，也不想看别人的代码），但是观察别人hack我的经验，主要是构造极端的数据，比如（-（-（-（-x))))这类数据。

四、重构总结

• 第二次作业的重构：这一次重构是对之前的完全推翻，建立了factor、item、expr等明确的类（详见第一条的类图对比），意识到数据不同应该建立不同的类。同时，括号嵌套成了最大的麻烦，如何处理递归调用是核心问题。所以按照求导的流程来进行书写。虽然意识到了自己对数据划分不对，但是仍然没有醒悟修改正则表达式，这也引发了我的第三次作业小规模重构
• 第三次作业的小规模重构：由于之前的作业都对表达式进行了预处理，书写的代码也是基于预处理之后的式子，所以导致我不得不重构。加入格式判断很简单，只需要正则匹配即可。但是由于表达式因子要求括号内部两边必须要有空格、表达式可以自带符号等问题，让我重新书写了正则表达式。对此我认为，在书写代码时，一定要跟着规范和需求，不能够太过于违反题目本身的意思。（同时，提前了解到需求也是很重要的，不然就会不停重构）。

五、心得体会

三周以来每次作业基本都会花一天的时间构思，半天写代码，半天debug。尽管如此，我仍有很多地方考虑不够全面，比如提取系数、指数这类就应该封装进单独的方法里，而不是在解析方法里不断重复，导致代码臃肿不堪。所以在写代码的时候，也应该提前规划好要实现的功能，可以提前拟一张表格，这样会更清晰。

作业压力很大，很多东西都得自己预习来做，当时觉得很困难，甚至为此哭了一次，但是如今想来也没那么难。很多东西从初见到熟识都需要一个过程，学习也没有捷径可言，所以希望下次作业的我不要太畏畏缩缩，相信自己的能力，认真去实现。

BUAAOO 第一单元

原文：https://www.cnblogs.com/zhuxixi/p/14589994.html