OO_Unit1_Review
一.作业结构的度量分析及BUG分析
1.Work1-简单多项式求导
1.结构
第一次作业我在主类MainClassHW1外，还创建了对项求导输出的类StaTerm1和提取单项中幂函数次数、系数的类NaTerm1，MainClassHW1负责输入多项式，并通过正则表达式分解多项式为单项式，并将单项传入NaTerm1中通过正则表达式匹配提取各个属性，最后将单项的属性传入StaTerm中求导并输出。
UML
A.类复杂度
B.方法复杂度
2.BUG分析
BUG概括：本次作业我主要的BUG只有一处，在分析单项属性并输出的过程中，我采取了同步输出的策略，即按照n*x**m的顺序输出，当n==0时不输出项，这就造成了一个BUG，就是当整个多项式求导的结果为0时，输出结果为空，这个低智BUG导致我在互测环节被狂刀20次。
解决方法：针对这个BUG的解决方式也非常简单，就是取消同步输出策略，转而向NaTerm中传入一个空字符串printStr，将求导输出的内容strcat到字符串末尾，最后在MainClass中判断输出，若printStr为空则输出“0”,否则正常输出。
2.Work2-包含三角函数的多项式求导
1.结构
此次作业相比上次作业，结构变化不大，唯二的区别如下：
A.在NaTerm中添加了解析单项三角函数的类方法，同样通过正则表达式匹配实现。需要注意的是在提取幂函数的次数时，为了避免将三角函数中的 (x) 匹配，需要用到 (?
B.此次作业除了空格不保证输入格式正确，故在MainClass中设置一个Judge的类方法，以大正则表达式来匹配整个字符串的格式。并提取幂函数次数来判断次数限制。
UML
类复杂度
方法复杂度
2.BUG分析
BUG概括：本次作业的BUG集中在输出内容的格式错误，由于在StaTerm中Output的代码缺陷，会出现形如+*x、+*sin(x)的格式错误。
解决方法：解决方法也相当简单，只在输出环节运用replaceAll的方法来将“\\+\\*”和“-\\*”替换为“+”和“-”即可。
3.Work3-复合多项式的求导
1.结构
由于此次作业的逻辑性的复杂，我在结构上做了较大调整。调整如下。
A.由于此次作业格式判断的复杂性，我将MainClass中的Judge单独整合到新的JudgeStr类，由于多项式的复合性，通过递归来判断整个多项式。
B.由于此次作业需要用到较多的字符串规范，于是我将所有字符串规范处理整合到ModStr类。
C.创建PrintStr类负责输出环节，创建DealStr类负责提取单项属性并调用PrintStr类输出。
D.由于多项式的复合性，无法像前两次作业一样先处理后输出，只能一边处理一边输出，同时需要通过递归方法处理输出表达式因子。
UML
类复杂度
方法复杂度
2.BUG分析
A.BUG概括：a.当表达式因子前为负号时，无法提取正确系数-1；
b.当多项式中出现多个表达式因子时无法正确求导输出；
c.当含三角函数和表达式因子的单项系数为0时输出错误；
B.解决方法：此次作业虽然BUG数量多，但多是我在移植上次作业时出现的瑕疵，因此解决起来也比较得心应手。第一个BUG稍微修改正则表达式即可，第二个BUG在每个表达式因子输出其求导结果后继续输出其他表达式因子，第三个BUG添加特殊情况判断输出即可。
二.寻找他人程序BUG的策略
在寻找他人程序的BUG时，我主要专注于一些特殊测试数据。如：
1.系数为0的项式，如0*x**10；
2.次数为0的项式，如10*x*0；
3.含有复合加减号的项式，如+--、-+-；
4.使用指导书规定的边界数据；
三.对面对对象的思考
我认为此次作业，我有一定的面向对象的思想，比如HW1和HW2中应用StaTerm来求导输出，用NaTerm来提取信息，以及HW3中将主函数中的静态函数封装到PrintStr和ModStr，但是我认为我的面对对象的思想仍然停在使程序逻辑更缜密，过程更美观的层次，并没有用上继承等方面的知识。同时如果采取工厂模式或许可以使得代码的可读性更加高。
四.心得体会
我认为此次作业虽然我采取了一定的面对对象的思想，但是随着作业难度的一次次的加深，仍然出现了逻辑混乱、面向过程的陋习，比如第三次作业中，在最关键最复杂的DealStr类中，在很多重复的功能处我代码的耦合性不高，这客观上造成了代码的繁琐复杂，也间接导致了我在移植HW2功能中出现了不少的漏洞，以至于在互测环节因为一些小漏洞被刀得飞起。当然一方面也有ddl过紧无法从容不迫地优化代码，另一方面也是我个人偷懒心理所致。同时，也由于我的偷懒，其实没有非常优化输出，其实简单地只靠一个HashMap就可以很大程度地简化输出。