OO第一单元总结
1.分析程序结构
第一次作业
类图
第一次作业用了8个类，但是我对面向对象思想还不熟悉，所以用这些对象、方法时还是本着面向过程的思想的，用起来就像c语言的函数，所以逻辑显得十分混乱。
类图
第二次作业因为复杂度只是稍稍增加，所以尽管我在研读指导书的时候设计了基于factor和expression的对象，但是在实际编写代码的时候发现，沿用第一次垃圾的设计能省不少时间，所以又是一次没有面向对象的作业。（代码完成后发现甚至比第一次还要烂）。
第三次作业
类图
第三次作业没有一个精妙的设计根本无法下笔。我设计了9个类，其中PolyLegal类用来输入和判断合法，Symbol类是一个抽象类，Add、Mul、Sin、Cos、Pow类继承自Symbol类，BuildTree类用来建立表达式树。所以在对表达式进行建树、求导、返回字符串时，表达式不用分清是哪种运算（ +*sin cos ），因为可以用多态使整棵树就Symbol一个类型。由上图可见，判断合法性和建树这几个方法的复杂度和紧密程度很高。但是我写的部分类还是颇显臃肿，比如在checkExpression和checkFactor中，还是有面向过程的思想在里面。此外在判断表达式时用的正则会贯穿整个程序，但我没有将其独立出来，所以导致修改一处正则错误需要牵动多处修改。
我的判断输入合法的思路是，沿用第二次作业对有符号数字、幂函数、三角函数等基本因子的正则判断，遇到表达式因子时，将其换成x并扔进checkExpression方法进行递归，遇到嵌套因子把括号内的内容换成x，并扔进checkFactor方法进行递归。我的求导思路是，把整个表达式建成一个树，树的结点是运算符（其中我把sin和cos也看成运算符）。每个运算符节点继承自一个抽象类，节点下用arraylist记录其分支。五个子类（ +*sin cos x ）重写derivation、toString、clone方法。
2.bug分析
公测中都没有出现bug，互测中第三次作业被hack了两次，都是因为正则的错误。但实际上这个bug在我第一次作业中出现过，并且还帮助同学解决了这个bug，所以再次发生真的不应该。实际上这个bug是可以避免的，我在处理正则的时候选择要用的时候复制一下，没有单独用一个类。当我检测出 sin（x）^10000 程序出错后，我在Sin这个类中修改了正则，但我忘了Cos和PolyLegal这两个类里也有相关正则，这就埋下了一个bug。
前两次作业的课下bug都是在条件嵌套时发生的，并且在手写测评机的大量测试下都修改过来了。第三次作业因为用了大量递归，所以比较难调试，找到bug后要经过很长时间才能修复。但在此过程中我也对idea的debug模式更加熟悉了。
3.寻找互测bug
第一次互测有少数问题。
-
大部分人第一次接触空白字符，没有考虑换页符和垂直制表符。
-
没有在提交当天下午看水裙，错失了修改爆栈的bug的机会。
-
规则不够完善，出现一个bug后就会被群起而攻之。
-
提交前的调试不够充分，很多bug都是出现在只有一项或者
*0和+0这种地方上。
第二次互测中我使用了对拍器。在对拍器的帮助下我找到了我们组大部分bug。
第三次作业由于无法提交 WRONG FORMAT! ，所以需要需改提前准备好的正则。实际上在没修改前跑的程序根本没法看，隔不了几组就有格式错误漏判或误判。调整后找到的bug大多出现在嵌套因子的判断和递归返回时加不加括号上。此外还需注意输出格式也要正确，同组有不少人输出表达式因子时没有加括号。实际上被hack次数少的人bug不一定真的少。
（对拍器大致思路：用python Xeger包生成测试数据，得出结果后用sympy算出正确结果并互相比较，用指导书的判断正确错误的方式决定是否报错。）
4.对象创建模式分析
这几次作业都可以用工厂模式，我的构造模式类似与此，但是我没有用接口，且对象需要判断类型再实例化。
总结
