OO第一单元总结博客

零优化就是最好的优化。

本单元总结博客我将分为以下五个方面撰写。

(1)基于度量来分析自己的程序结构

第一次作业

• 第一次作业用的是一个不太面向对象的方法，类图如下所示：
  
• 主要用到的是两个String类型的处理函数，也就是replaceAll()和.split()方法，这里贴出部分代码，就不再赘述了，因为一点也不面向对象。
  

OO度量如下所示：

第二次作业

• 由于第一次作业的方法过于粗暴，无法处理第二次作业中嵌套的表达式因子，因此第二次作业被迫重构。类图如下所示：
  
• 本次作业开始，采用了递归下降分析法，由于二、三次作业架构相近，故下文一起分析。这里先贴出OO度量数据：
  
  
• 第二次作业中的接口值得一提。
  • 设计思路：
    因为本次作业中三角函数内部只能为x，不会有嵌套的三角函数或表达式因子等，因此可以把各个表达式因子的括号全部乘开，化成若干个由常系数、x的指数、sin(x)的指数、cos(x)的指数这四个BigInteger组成的四元组而完全确定的项。再考虑到x的指数、sin(x)的指数、cos(x)的指数更能刻画项的性质，这三个指数相同时无论常数是否相同均可合并，于是把三个指数封装成Expo类，作为Map的key，再用常数作为Map的value，即可起到合并的作用。
  • 优点：Expression类、Term类、Factor类下设属性完全一致，代码清晰易懂，如行云流水一般一气呵成……
  • 缺点：上限80分。

第三次作业

• 由于第二次作业集简约风之大成的美妙属性设计，第三次作业果不其然花了大量时间重写接口……然鹅，递归下降的核心架构被保留了下来，继续发光发热。第三次作业的类图如下：
  
  OO度量有关数据如下：
  
  
  
• 今天新闻的主要内容有：
  • 主函数main用于读入字符串
  • 工厂类Factory用于递归下降地分析、“拆解”字符串
  • 表达式类Expression、项类Term、因子类Factor用于保存不同层次的表达式信息，其中Factor有5个子类，分别用于保存常数因子、幂函数因子、正弦函数因子、余弦函数因子、表达式因子。

(2)分析自己程序的bug

• 由于不优化，所以……没什么bug，基本都是语法相关。
  下面是我第三次作业的运行结果，生动形象地体现了零优化代码的精确与高效：
  
• 第二次作业中有一个印象深刻的bug
  • bug核心：BigInteger n = BigInteger.valueof(str.charAt(i));
    这行语句看似正常，实则会读出来ASCII码并传给n……找了好久才定位到这里，修改前全跪，修改后通杀（？）
  • 解决方法：可以改写成BigInteger n = BigInteger.valueof(str.charAt(i) - '0');，即可正确读到并保存想要的数字。
• 第三次作业的强测中，我满怀信心地……WA了一个点。而且是个WRONG FORMAT，也就是说，对于我的零优化代码而言损失了一个宝贵的100分。找来找去，最后发现报错出自于无意义的辅助信息输出。
  • 作业要求中指出：“对于输出结果，如果包含多行，则在评测时将忽略第一行以后的内容。（也就是说，你们可以在正文之后附加一些其他的信息以改善自己调试的体验）”
  • 于是我愉快地输出了报错出自的函数，还输出了出错位置的下标以及此处的字符。结果忽略了数据结尾出错的情况……由于索引i始终指向即将被处理的字符，此时如要强行输出String在此越位位置上的字符则会产生下标越界错误。
  • 解决方法：多余内容注释掉，不然还能咋样（x）

(3)分析自己发现别人程序bug所采用的策略

• 非常抱歉，我能力有限没能发现别人程序的bug。。。但这并不妨碍我勇于尝试hack别人（不是）
• 在互测阶段，我尝试过的测试用例有：
  • (((((((((((((((((((x)))))))))))))))))))
  • sin(cos(sin(cos(sin(cos(sin(x)))))))**9
• 这两个测试用例的出发点在于测试别人的程序会不会爆栈。但事与愿违，斩获0/14的优秀战绩

(4)重构经历总结

• 只重构了一次，即第二次作业开始时，使用了递归下降分析法重新写了程序，主要部分已在上文说明。

(5)心得体会

• 痛并不快乐着。
• 零优化就是最好的优化。
• 终日而思，不如须臾之所学也。