OO第一单元总结
第一次作业
设计思路
此为面向对象第一单元的第一次作业，要求是完成简单多项式求导函数的任务。其中包含表达式、项、因子等概念。个人的这次设计思路处理方法上面向对象思想应用不太够，个人先将表达式中的空白字符去掉，并且对正负号进行合并，然后建立了一个PatternClub的生成正则表达式的工厂（但有点大材小用），利用正则表达式去拆分表达式，并匹配各种因子，而这次作业我把所有因子都归结为一种Factor（实质即为广义幂函数），经过ToFactor的求导，最后输出。
优化主要在合并各个同类项，对符号进行合并，值为0的项不进行输出等等。
类图
度量分析
方法分析
类分析
本次作业代码总行数313行。
由上述可知，在OutPut和ToFactor两个类中的复杂度较高，主要应该是大量特判而导致。
优缺点
此次作业优点方面的话是刚开始接触OO能够把字符串拆分成各个小的类，然后化繁为简地去处理问题，但缺点是设计的可拓展性太差，导致后来出现重构，且由于设计，导致特判过多，程序复杂度高。
bug分析
此次作业在强测中错了一个点，bug主要是当多项式合并后，如果最后合并完是0的话，最后没有输出。在互测中也是因为这个被hack了。后来在输出中加了一个特判而解决。
第二次作业
设计思路
第二次作业主要是完成包含简单幂函数和简单正余弦函数的导函数的求解，除了第一次作业已有的相关概念，又增加了三角函数因子、表达式因子。由于本次存在着递归嵌套因子的存在，所以个人此次整体设计思路为利用递归下降的方法将输入表达式进行处理，从而得到表达式、项、因子。求导过程即是从底层因子开始往上求导，最终构成表达式的求导。
优化方面个人主要对0*factors进行了优化，还有合并了部分同类项，但较为遗憾的是由于优化导致程序设计思路出现混乱，出现重大bug。
程序结构
类图
度量分析
方法分析
类分析
此次作业代码行数总计1041行
由上述分析可知，类中的toString方法以及Factor类复杂度较高，三角函数因子的toString是由于特判过多，而Factor是由于其中的求导等方法未使用接口来实现，全放在了Factor中，导致其复杂度较高。
优缺点
此次作业优点在于运用递归下降处理程序，把整个输入表达式化为从顶层的Expression到底层的Factor的一个递归结构，求导或者合并处理起来相对简单一些；但结果化简方面做得并不是很好，且由于优化致思路混乱，导致程序正确性出现错误。
bug分析
这次作业可谓是印象深刻，由于在因子到项，项到表达式的toString变化中，各个类的符号输出出现问题，导致强测错了很多点，以致未进入互测，但bug修复只改了三行便全过了，只能说教训深刻。
第三次作业
设计思路
本次作业需要完成包含简单幂函数和简单正余弦函数及其嵌套组合函数的导函数的求解。此次在上一次作业上加入了格式检查，以及嵌套的三角函数。由于格式检查，在处理输入字符串的过程便变得很复杂，且需要不断在其中抛出异常WrongFormat，其他的类基本不需要改变，除了在三角函数因子类中加入一个表达式因子，稍微改变其求导的方式便可。
优化方面由于上次优化出现了bug，导致这次个人不太敢进行优化，这也导致最后强测的性能分极低。
程序结构
类图
度量分析
方法分析
类分析
这次作业代码行数总共有1277行。
由上述分析可知，除了第二次作业已有的构造缺陷toString和Factor，这一次由于多了格式检查，StringSolve字符串处理复杂度大幅提升。
优缺点
此次作业优点在于由于上次作业结构的良好，迭代开发不太难，且整体结构比较清晰，但缺点还是十分明显，代码结果的优化基本等于没优化，导致性能分过低，且处理字符串的过程中，判断过程比较复杂且繁琐，导致此模块复杂度较高。
bug分析
此次由于大体架构和上次作业差不多，则基本上bug只会出现在格式检查和三角函数嵌套上，个人强测未测出bug，但互测bug是出现在处理三角函数中的空格以及字符串最后的空格，会出现误判WrongFormat。
测试bug策略
个人在互测中测试bug未采用评测机或是自动生成数据，基本上都是根据指导书上的形式化定义，自己构造相应的易出现错误的样例，比如第一次作业中合并同类项的样例（+++123*x*x*x-+123*x**3）、多个加减号在一起出现错误（-+-2*-2*x*1231*x*23*x** -3+-+123*x**1），第三次作业由于前两个次作业的基础，这种方式便难以找到bug，但围绕着三角函数嵌套还是能找出少数bug，如- sin ( ( x+ -x**1 +x) )样例，较多的是在格式判断上把正确的误判成了错误的格式。
重构经历总结
本单元作业在第一次作业和第二次作业之间，个人大幅度重构了程序架构，第一次采用的只是很为简单的字符串拆分，其在之后出现嵌套或递归后难以继续，所以只能另外采用其他思路，所以新学习了递归下降的解决方法，便可以较为方便地解决复杂的需求。这次重构后，在第三次作业便基本无需太多改动，便可以完成需求，所以重构后的结构以及思想还是较为不错的。
从这次重构的教训，我认识到不能把问题想得过于简单，要留给后续棘手问题以及自己一条后路，能够给程序以较强的可拓展性。这是在设计之初便应当思考的。
心得体会
此单元作业为个人第一次接触面向对象，可谓是经历坎坷，该经历的基本都经历了。三次作业的总体框架在第一次到第二次之间的重构发生巨大变化，且代码量也不断增加，尤其是在第一次到第二次的过程中。个人对于面向对象的理解也在那一次作业中得到深刻的教训。总的设计模式也随着作业的迭代，不断得到改善。有一点遗憾的是最后结果的优化，除了第一次优化较好，之后的两次优化都较差，而第二次甚至由于优化，导致正确性的失去，确实是得不偿失。
