总体
第一单元总主题为表达式求导，三次作业分别的要求为多项式求导，带有幂函数、三角函数的求导和最后一次带有嵌套和表达式因子的求导。下面是每一次的结构分析。
第一部分 分析代码结构
第一次作业
UML结构图
耦合度分析
第一次作业的整体结构非常简单，由于刚刚学习面向对象课程，还理解的不够透彻，思想还基本停留在C语言 和数据结构的层面上，运用hashmap存入每个指数和对应的系数最后再求导输出，但还算好的是没有真正的一main到底，内部的每个方法之间仍然有意识的进行了少许划分，在与同学讨论的过程中开始明白面向对象的具体思想，在第二次作业中开始实践。
第二次作业
UML结构图
耦合度分析
第二次作业的大体结构为：
1.输入部分，此时调用Formalization类对表达式单独进行WF判断，使用try-catch结构捕获异常，然后使用Deformation类对表达式进行变形以适应之后的要求。
2.合并部分，我的想法是将表达式分为一个个小项进行分析，调用Handlefactory类在内部对不同的因子进行不同的筛选判断，此时具有了一些创建工厂的模子，但还未运用接口和继承类，仍在内部进行。
3.再合并部分，是一个可拆解的简化类，由于担心简化会出现更多无法预知的bug，就只运用了sin^2+cos^2=1和cos^2=1-sin^2两条规则进行少许化简，同时时间比较紧，没有太关注耦合度的问题。
4.输出部分，与第一部分相似，增加了一个筛选第一个项是否为正的环节，显得比较臃肿。
第三次作业
UML结构图
耦合度分析
第三次作业的大体结构为：
1.输入部分，结构基本一致，但由于第三次作业多了嵌套和表达式因子的关系，不能使用大正则进行整体判断合法性，因而使用了递归的思想，先判断每一个三角函数，再判断每一个多项式，以此递归直到都再找不到新的，替换成固定的其他字符，最后再使用大正则进行判断合法性。之后再使用Deform类，照上述的过程同样进行操作，并将对应的三角函数和多项式用栈保存，将表达式分为一个个小项进行分析。不足点是Form和Deform重复度太高，导致debug时容易遗漏。
2.合并处理部分，本来想要使用树的处理结构，但写到后面发现不太能消化处理这种模式，最后仍然采用了第二次作业的方式，分隔成一个一个项进行处理，由于有嵌套和递归的因素，进行了表达式的和三角函数的混合递归，写的时候十分痛苦，bug也非常非常的多，耦合度的问题也不尽人意。
3.输出部分，由于没有进行化简，直接在combination完成后进行了输出。
第二部分 分析BUG
第一次作业
第一次作业强测中没有发现bug，但在弱侧中+-x**-1的例子中，没有处理好*号，导致会输出+-*x**-2的数据，被hack了17次，所幸经过合并修复没有扣掉太多分数，但也让我发现了输出类的巨大问题，在第二次作业里面进行了更改。
第二次作业
第二次作业在强测互测中都没有被发现bug，由于第一次的教训，第二次自己测试的十分仔细，对每一种情况都在写代码的时候手动构造了样例进行判断正确性。
第三次作业
第三次作业没有通过弱侧weak5，进行了一天的测试代码依然没有发现问题，最后结束之后发现问题出在很小的地方——toString一部分没有写全，但是自己却并没有测试出来。
第三部分 分析自己发现别人程序bug所采用的策略
第一次作业
第一次的作业由于比较简单，而且强测没有测出我的bug导致进入A房，没有测到其他人有bug，但是好处是通过阅读其他人的代码学习到了新的架构方式，为第二次作业很快写出打下基础。
第二次作业
第二次作业使用了随机生成的数据对其他人的代码进行广撒网，最终捕获到一个bug，优化过度出现的问题。
第三次作业
第三次作业未进入互测阶段。
第四部分 应用对象创建模式来重构
通过前几次的作业和研讨课、网课的学习，逐渐从面向过程的思想转换到面向对象的思想，虽然还没有转换的很好，第三次作业最后也出现了问题，但是问题不在于对对象创建模式理解的问题，而在于自身仍然不够熟练，导致写的时间非常长，最后debug已经没有充足的时间，课后已经通过询问和再回溯的方式发现bug并进行了修正。
第五部分 对比和心得体会
面向对象和面向过程的区别现在感觉在于抽象的程度和层次性，如果层次感和具体架构不清晰，最终只能走到面向过程的路上，并且程序的可塑性和健壮性根本得不到保证，bug也极难通过分模块测试的方式找全，从而导致第三次作业的惨剧，每次作业也基本上进行了重构，身心也是非常疲惫，还感觉自己没有学到什么。通过这次教训，让我深刻领会到面向对象写作的重要性，在下笔之前一定要充分分析层次和架构，将一个问题进行充分的抽象思考，并且要考虑之后程序的迭代性，才能让自己至少学的没那么累，也更有效果。