OO第一单元作业总结
OO第一单元作业总结
第一次作业
（1）度量分析程序结构
UML类图：
方法复杂度分析：
类复杂度分析：
第一次面向对象作业，当时我还没有面向对象的概念，只是模仿着舍友写了这三个类，其实心里并不清楚为什么要分成这几个类。很多地方都是凭感觉写，不符合面向对象的思想，比如当时没有在Mo类里写输出函数并由Poly来调用，而是在Poly类里面写完所有的输出，没有转换成字符串而是直接输出，这就导致了我Poly.print()方法过于复杂。
（2）程序bug
强测之前发现的bug是自己写的长正则导致爆栈，当时的写法是直接匹配整个输入，因为写之前觉得一项一项匹配太麻烦，之后没办法还是改成了一项一项匹配，写起来也没有想象中那么麻烦，在互测时也发现了其他大佬用独占匹配整个输入也不会爆栈。为了追求简单，我在判断合法性之前就去掉了空字符，当时是直接去掉所有空字符，把不合法的制表符也去掉了，所以有些本该是格式错误的输入我还是将其判断为合法。
互测时被发现的bug是没有判断项与项之间的加减号，导致很多非法数据我都判断的合法。为了拆分时简单，我将表达式中的符号进行替换（++换成+，+-换成-，-+换成-，--换成+，-换成+-，+换成），这样就能直接用+来拆分每一项了，但在替换前要判断表达式是否合法，而我在判断合法时出错了，没有考虑到^后面最多只能有一个符号的情况。还有就是这次作业我是直接输出，为了将负号置后我写了swap()方法来调整输出顺序，具体判断方法是如果有正项就把正项提前，如果没有正项且第一项系数为0，就把第一项和第二项交换，当时觉得如果最终结果不为0的话第一项是绝对不会为0的，所以输出时如果第一项系数为0，那么我整个输出就是0，没有考虑到所有项都是非正项且第一项第二项系数为0的情况，导致我很多时候都输出的是0。
（3）发现别人bug的策略
首先还是把之前测出我bug的数据让每个人都测一遍，确实发现了有人和我犯同样的错误，之后就是看有没有人正则表达式写错，虽然没有发现有人正则写错，不过还是学到了其他大佬正则表达式的写法，写的很整齐。最后就是自己瞎造数据，弄一些临界数据，最终还是找到了别人的bug。
（4）Applying Creational Pattern
感觉并不需要创建模式。
（5）总结
本次作业的亮点，首先是去掉了所有的空字符（虽然没有考虑全面导致bug），这是舍友想出来的，不过用起来是真的方便，让后面正则表达式短了很多，不过在去空白字符前要判断空白字符的合法性。之后就是符号替换并用加号分割每一项（虽然也没有考虑全面导致bug），这同样是舍友想出来的（可见我的舍友是多么的优秀），这使得在把表达式拆分成每一项时的工作量大大减小，不过在替换前要判断符号的合法性。
第二次作业
（1）度量分析程序结构
UML类图：
方法复杂度分析：
类复杂度分析：
第二次面向对象作业我有了一定的面向对象思想，知道了什么时候该分类，并把输出输出单独分类，而不是放在Main里面处理。因为加了三角函数并且输出要化简，所以比第一次复杂了很多，由图可以看出复杂度高的类是多项式类和项类，其中复杂度高的方法是构造函数和化简时使用的方法，因为在输出方法中条件语句用了很多，所以导致输出时复杂度很高。
（2）程序bug
强测之前发现的bug主要是对可变类型处理时没有clone，导致在一些方法里面不小心更改了对象的值。还有就是在循环体里面随意插入删除导致循环体无法正常运行。也多亏了我那优秀的舍友为我耐心讲解我才能弄明白（舍友tql）。
因为这次课下花的时间比较多，互测时只有一个bug，就是优化四次方时把一个变量弄错（还好强测没测出来），不得不说，深夜写代码效率实在太低，稍微不注意就写出了bug。
（3）发现别人bug的策略
基本上和第一次一样，先用测出自己bug的数据，再自己编数据，由于这次代码太长，我也没仔细看，导致最后好多人正则写错了我都没发现。另外，我还把舍友写的对拍器要了过来，虽然一个bug也没测出来，不过我也体会到了对拍器的强大。
（4）Applying Creational Pattern
个人感觉这次作业需要在构造每个因子时使用静态工厂模式，这样不必每次调用的时候都创建一个新对象，可以返回原返回类型的任何子类型的对象，十分方便。
（5）总结
第二次作业我是完全重构了，并没有采用
的写法，虽然这种写法写起来很简单，但我的大佬舍友说这样写不满足面向对象的思想第三次肯定要重构，我也觉得很有道理，就把幂函数，正弦函数，余弦函数都单独列了个类，不过当时写的时候还是感觉有些复杂，还好坚持写完了。
本次作业的亮点我认为是明确的分类使代码的可扩展性提高了不少。运用了工厂方法，使构造变得简单。每个类都写了clone函数，使化简变得简单。写了四个优化函数，分别是优化
说到底都是sin(x)2+cos(x)2=1，不过我用的方法无法递归化简，所以每个不同次数的式子都要单独判断，这里就不写出来丢人了。
第三次作业
（1）度量分析程序结构
UML类图：
方法复杂度分析：
类复杂度分析：
第三次作业多了括号和嵌套所以更加复杂，导致判断合法性的方法也变得复杂，其他地方和上次一样，化简的方法复杂度高，由于加法类和乘法类一层套一层，所以复杂度很高。其实可以把优化部分单独分一个类，这样也能减小加法类和乘法类的复杂度。这次作业的构造函数没写好，每一个构造函数都是50几行，最后bug修复时还因为构造函数超过60行无法在里面直接修改，造成了很多问题。
（2）程序bug
这次作业由于自己最后写的构造函数，导致自己一直都不能进行测试，所以在写完后有很多bug，这也算是一个教训吧。
强测前发现的bug：首先是多项式拆单项式时忘了判断前面的负号导致最后结果错误；没有判断嵌套函数内层函数如果是多项式因子就要多加一层括号，导致很多格式错误没判断出来，输出嵌套函数时如果内层为多项式因子也少了一层括号；没有判断嵌套函数内层的符号和内层因子之前不能有空格；提取公因式时忘记remove导致重复提取。
强测以及互测时发现的bug：这次没有前两次那么幸运，终究还是被强测测出bug了，当时在强测前就发现了这个bug，只需要在乘法类的构造函数加一层判断就行，不过乘法类的构造函数已经59行，无法继续添加，我只鞥在别的地方改，然后没考虑全面导致被测出bug。
然后这次还有强测互测都没有被发现的bug，也是十分致命的bug，那就是在每个equal函数里我都没remove，举个例子来说就是(x+1)*(x+1)与(x+1)我的equal会判断这两个相等。因为我是直接复用的第二次作业的代码，在复用前也没仔细想能不能直接复用，这次多了多项式因子所以必须要remove，我在化简的时候考虑到了然而却没想到要在equal里面加。这个bug是我在测别人化简有没有remove的时候不小心把自己测出来了（自作自受）。
（3）发现别人bug的策略
基本上和前几次一样，这次把对拍器优化了一下，感觉更好用了！！！
（4）Applying Creational Pattern
这次作业可以在构造函数时使用静态工厂模式，在写公共基类时可以采用抽象工厂模式，这样能很好地解决接口选择的问题。
（5）总结
这次作业括号去的很好，能去的括号都去了。化简由于怕超时所以没用递归只化了最外面一层。不过bug太多了，很多都是自己过于相信自己逻辑没问题，但事实上考虑有所欠缺，以后应该把不可能出现的情况也写出来抛异常，在复用前一定要谨慎，不能觉得可以就完全复用，问题应该考虑全面。
