基于度量来分析自己的程序结构
第一次作业
第一次作业整体来说比较简单，而我在码代码的过程中也是大部分基于面向过程，没有考虑程序的可扩展性等。
类图如下：
度量图表如下：
复杂度分析：
尽管是第一次很简单的作业，仍然出现复杂度爆炸的情况，我们可以看到是Diff类中的getCoe方法，在写这个方法时，我采用的是对项从头开始一点一点解析，判断多种情况从而得到正确的系数，导致复杂度较高。但我读入时采用了正则表达式，若将正则表达式应用于提取系数（指数），那么将是简单不易出错的方法。
依赖程度分析：
第二次作业：
由于第一次十分糟糕的代码，第二次作业重构。一开始本想留出可扩展的余地，构造了一些类等，但是思路混乱，感觉要做不完了，不得不推翻，最后采用了三元组的方法，仍然没有很好地应用面向对象的思维。
类图如下：
将很多方法堆积在main中，没有做到根据不同的功能建立相应类等。
度量图表如下：
第二次作业对于我采用大正则的方法，暴力读入整个表达式，若不符合，则直接WF，若符合再一个一个项读入。GetAndDiff将得到项和进行求导放在一起，归根结底还是面向过程惹的祸，并且得到项还是利用条件判断一点点解析，没有很好地利用正则表达式来提取；judge方法也是，在判断项的符号时，将15种情况暴力列举利用条件语句判断，导致复杂度过高。还有toStr方法，更是不应该出现在Main中，而是应该写在Key中。总而言之，是在没有充分理解面向对象的情况下草草下手，导致诸多弊端。
复杂度分析：
依赖程度分析：
第三次作业：
再次重构，由于第二次作业的草草收尾，第三次作业再次重构，刚刚开始时，确实考虑了课程组推荐的方法，但实施时思路混乱，不知从何处下手，所以只好硬着头皮自己边想边做。
类图如下：
这次的类图极其丑陋，我没有把正则表达式都归在一个class中，而是每个class用啥，我就复制过去点啥，导致修改时很不方便。
度量图表如下：
这次的复杂度就更不用说了，毕竟是混乱之中一点点拼出来的代码o(╥﹏╥)o
复杂度分析：
这次的作业从一开始的没有思路，然后面临着做不完的风险，同样是边做变想，并且大量运用循环判断等，所以复杂度爆炸。
依赖程度分析：
（这三次作业没有优点，都是缺点，没有使用接口、继承等，透露着一股浓浓的面向过程气息，代码混乱。
分析自己程序的bug
在第一次强测和互测中，没有被发现bug；
在第二次强测中没有发现bug，在互测中被发现了2个bug：
在判断指数的范围时，我采用将限制位数的方法，忘了考虑前导0的存在；
在化简时，由于对sin(x)项和cos(x)项相差次数为2时进行了化简，此时会产生新的key，我直接将其put进了容器中，没有考虑到如果该key已经存在，那么该操作会覆盖之前已有的value，最后采用递归的方法进行更改。
在第三次强测和互测中，发现了一样的一个bug，问题出在我在化简是，将*1(*+1）直接去掉，误以为这样可以去掉所有的乘1的项以达到简化的目的，但是没有考虑到可能会有*1212这种情况的出现。
分析自己发现别人程序bug所采用的策略
首先我会用自己出错的bug来测试别人的程序；在前两次作业中，然后再阅读正则表达式部分；在第三次作业则是根据一些通病问题，比如有的人的程序在处理多层括号时会出现运行十分缓慢等状况等。
应用对象创建模式
homework3中，factor的创建可以使用简单工厂模式：根据type，创建相应的factor，并进行相应的合法性检查。（根据原来的方法即可）
对比和心得体会
大佬的代码分工明确，代码简洁，合理使用继承、接口等，我的代码实在是看不下去。
在做第一次作业时，感觉很幸福；在做第二次作业时，感觉有点不对劲，隐隐约约地看到了OO的真面目；在做第三次作业时，OO露出了真面目，感觉很痛苦。在前两次作业时，感觉还行，没有很痛苦；在做第三次作业时，由于我再次重构且思路混乱不堪，一度十分绝望甚至觉得自己做不出来，但是慢慢还是做出来了，甚至只错了一个点，虽说代码质量不咋地，但对于菜的掉渣的我来说，还是有一丝丝欣慰的，至少再次实践了坚持就是胜利的小小道理。在以后做作业的过程中，一定要逼迫理清思路，草率下手的下场就是痛苦地debug，自己都看不懂自己的代码。