写在开头：
第一次接触面向对象思想和java语言，在学习以及完成作业的过程经历了一个比较痛苦的过程，
虽然在每次写作业时总是会有一些小小的抱怨，虽然写出的代码还是很差，
但是看到自己有所进步，还是感觉到自己的努力没有白费。
一.代码分析
第一次作业：
UML类图
耦合度：
第一次作业时对oo的了解和对正则表达式的使用都还欠缺
在这次作业中使用了长正则表达式匹配的方法来判断WF
只是简单的分了表达式和项的类，表面上似乎是面向对象
事实上真正的实现逻辑还是没能离开面向过程
第二次作业：
UML类图：
耦合度：
在第二次作业中没有使用长正则表达式匹配，而是在经过预处理之后
进行一项一项地匹配
这次作业中每个项都可以化简成a*x^b*sin(x)^c*cos(x)^d的形式，因此只是简单地建立了乘法项，三角函数项
和幂函数项进行处理
但是每个类中方法很多，现在想起来预处理和求导都可以利用接口的形式实现。
第三次作业：
UML类图：
耦合度：
第三次作业的主要思想是对表达式做预处理之后，通过加号将表达式分割成项，再通过*将项分为因子
因子又分为表达式因子，嵌套因子，和幂函数因子。
那么在本次作业中，所有的输入经过分解后都会称为表达式，项和因子，
之后调用对应的求导函数即可得到结果。
然而在这个过程中，递归的次数非常多，所以这个架构是非常差的。
（对于有一点蠢并且对个人能力不自信而希望快速完成作业的本人来说，这个架构是最符合我要求的“傻瓜”架构）
在周日写完最初的不优化版本后，由于对过长的输出实在看不下去，开始进行简单优化，
（简单优化的结果是虽然达到了去掉多余01和去掉部分括号的目的，却出现了运行时间过长的bug）
二.程序bug
1.第一次作业被发现的bug使用了长正则表达式引起的爆栈，吸取教训后就没再使用过。
2.第二次作业的bug是在对结果进行优化时没有考虑到项的第二个因子的1*不能省略，导致出现了format问题
3.第三次作业的bug是优化之后导致代码运行时间过长出现bug，表明自己的架构和优化方法都很差。
三.互测
在前两次互测中使用的策略大致是先扫一遍其他人的代码然后挑几个人的代码
进行精确打击，这样的策略在第一次测试时还有一些效果，然而在第二次时由于代码量
较大，就很难通过看代码找出bug。
因此在看了讨论区大佬的讨论之后，写出了一个简单的自动测试脚本进行批量测试
来发现bug。自动测试果然是发现bug的杀器，使用它之后找bug的效率大大提高了。
在这里强烈推荐大家都可以写一个简单的自动测试脚本。写一个没有太多复杂功能的
脚本还是不困难的，像我这种小菜鸡也能写出来，相信大家都行。
四.一些感想
在看到第三次作业的强测结果后虽然也曾有后悔去写优化，
但是转念一想，这次优化失败能让我在以后的作业中去思考设计更好的架构
也能让我花更多的时间更多的精力去学习怎么写出更好的符合oop思想的代码
所以尽管丢了一些分，但至少做出了努力，也一定会得到一些东西。
还有就是学习oo一定要在实践中去学习，单单只听讲是不能真正理解的（至少对我来说是这样的）
只有写了一段代码去实现这个东西，才能真正对它有比较深的理解。
因此在接下来的学习中，会花更多的时间在实践中，争取能对面向对象有更深的理解。
加油加油加油。