BUAA OO 第一单元总结
18373599 崔建彬
###
1 基于度量分析自己程序结构
HW1
uml
复杂度
统计长度
可以看到第一次程序仍然是面向过程编程。基本属于一main到底类型。复杂度、耦合度较高。
可能也是因为第一次作业难度较低，仅面向过程：处理输入，处理求导，处理输出这样的思维就可以搞定。当然，这也奠定了后续需要重构的命运。
HW2
UML
第二次代码便是初次尝试 我认为的“工厂模式“进行编程。主要增加了Wrong Format的判断和Sin Cos的求导。虽说引入了factory package 但整体仍然摆脱不开 面向过程编程的思想。仍然是 Main负责输入输出，Poly 负责求导。 与第一次作业没有本质的区别。
从代码复杂度也可以看出。factor的子类几乎没有用到，而Poly和Main的耦合度太高，仍然是面向过程编程的思想。
HW3：
uml图
第三次作业较之前的作业有了较大区别。这次在处理Wrong Format 和 三角函数的基础上还要加上递归处理。
我看到的第一想法，是构建表达式树，奈何忘记了怎么中缀转后缀 而且对Java 构建二叉树不熟悉，遂放弃。后续便是受 课件启发，构建Poly（表达式）项，Term（将表达式用+/-）分割后得到的多项式，和Item（将term用*分割后的因子） + 乘法 / 加减法/ 三角函数求导 这种方法直接递归来做。但是受限于时间限制（因为是重构+重写），遂将第一版求导内容照搬，在运算中只保留了乘法类。
整体与前两次作业相比，减少了面向过程编程的思想，但是求导时，仍然是面向过程编程。导致其耦合度和复杂度较高。但是较前两次作业有了较大的进步。
2.分析自己程序的bug
1.HW1：
HW1比较基础，在强测互测和课下自己测试时候均未发现bug。
2.HW2:
HW2在强测中未出现bug，在互测中出现了如果一个项的幂次化简后大于50，也会输出WRONG FORMAT的bug, 主要原因在于对题目阅读不够仔细。有 一种“我觉得题目是这么要求的”的感觉。
3.HW3:
HW3的bug较多，第一个bug是 sin(- 1)这种错误的误判，主要原因是我先处理的空格错误然后去掉所有的空格，此时没有想到这种情况的产生。
第二个bug是 在处理括号的堆栈时，if判断语句出现了问题，导致最后错误。
这两个bug均在强测和互测中被提现到，一方面是做的测试不够全面，另一方面没有在写的时候做单元化测试。
3.分享自己发现别人程序bug所采用的策略：
简单来说 就是评测机+手动测试
评测机即用当前作页评测机，难度在于生成数据的随机性。随机性越强，覆盖范围越广，越容易测到bug。手动测试 即自己在 单元化测试、最终测试和（水群记录的数据）生成的边缘数据和一些较强数据。一般来说先输入手动生成数据，对那些没有问题的同学跑评测机，有问题的同学，继续手动测试另一组。
这样做的优点是确实找到了很多bug。缺点是，因为生成的数据过长，很多可能是同质bug。在这里也向那些一个bug被我交了2次及以上的同学表示道歉，因为我可能不是故意的。
4.应用对象创建模式来重构
三次作业三次重构。
第一次 即简单处理了读入求导，输出，并没有体现到很强的对象创建。给我的感觉就是把一个函数写成了一个类。
第二次用到了求导类，sin\cos等因子类，思路比较第一次时更为清晰，但同时对每个对象的职责仍不清晰，各个对象存在较多的耦合。
第三次作业重构了 乘法求导类，因子求导类，多项式类，分离后的简单多项式类，因子类。确实有了更为清晰的对象分类，但同时没有用工厂模式，时间紧迫写的比较乱，各个类交集比较多。
5.对比和心得体会
俗话说的好，没有对比就没有伤害。
阅读了优秀代码和私下优秀的同学的代码后，我觉得我们不是在学同一门课。
我个人确实有非常多的不足，无论是代码写作习惯，对java的理解还是态度方面都有欠缺。
写作风格就不用说了，容易函数过长，命名随意 如tempa等。
对java理解不够深入，不能很好的应用工厂模式，还没有彻底感悟面向对象的思想。
态度方面：我觉得态度方面我应该是欠缺的最多的。第二次第三次作业最为明显。在架构时，没有仔细考虑，觉得我想到了一个方法，就要赶紧完成。完成了以后，即使不是特别好，也不会想着重做。函数构造方面也是图快，导致经常出现一个函数过长。测试方面总是有一种迷之自信，甚至没有在最后提交前过一遍代码（第三次作业的bug，如果我提交之前过一遍代码，就不会出现了）。这些都是态度方面的不足。总感觉有一种应付作业的态度，而不是打破砂锅问到底的求知态度。不知道是在家学习氛围不好，还是经过一寒假休息习惯了。总之这是我觉得我目前为止最不足的地方，也是让我和其他同学差距越来越大的关键。希望在下一个单元，也能潜心研究课程，有所改进！