OO第一单元作业总结
OO第一单元作业之前有大概了解到什么问题，也听说重构的困难，所以每一次设计都会花费2-3天（基本最后周四才正式开始码代码）去设计，但是感觉用处不大。经常写着写着就忘记自己之前是怎么设计的，而且下笔的感觉都是在面向过程（虽然在设计的时候感觉自己的确是面向对象）。我认为第一单元主要有几点问题：
1、很多细节没有充分了解就去书写。关于容器自己只是大概了解有哪些之后就选择自己最熟悉的使用了，并没有进行过多思考，这导致了之后很多操作十分麻烦；
2、对于很多模式（比如工厂模式）了解不是很多，写的时候也没有过多思考，所以导致每个类干的事情有点多。
3、命名不是很好，或者自己英语水平不够，命名总感觉很奇怪。尤其是对字符串进行处理的时候很明显。
4、git分支使用不好，导致自己第二次作业第一次优化失败之后进行第二次优化后整个git一团糟。
第一次作业
UML图
度量分析
行数
第二次作业
UML图
度量分析
行数
第一、二次作业分析
思路
第一二次作业的思想差不多一致，都是用一个Term来保存一项，Poly用来保存一个表达式。对于每一个对Poly的操作，都转化为对Term的操作。在PolyDiff这个类，就完成了对字符串的处理以及对字符串的输入、求导和输出工作。
问题
相对来说由于类较少，每个类完成较多的工作，所以没有很好地结构特性。这在上图的分析中也能很好得出，PolyDiff写的的确很差。设计的时候一直在考虑什么叫做面向对象，所以对于方法的整理没有很好，方法和方法之间可能功能上有重合（甚至有的方法写了没有用），并且还是面向过程的思想方法导致有些方法超了100行还在疯狂删行。
对于正则表达式的字符串没有很好的维护，直接堆到了主类中，在自己调用的时候很麻烦。我认为应该有一个类去维护这些数据。
整个过程扩展性相对较差，在Term中很难完成嵌套（本身的扩项是想Term中原先用coe，xIndex，cosIndex，sinIndex来表达一项，之后可以再添加Term/Poly来保存三角函数中括号的内容，但是没有考虑到整个类的复杂度，第三作业被否定了）。同时对字符串的操作应该单放一个Parse类会好一点，不然这个样子PolyDiff干了很多本应该不是他干的活。
我一直是秉承着边读取边优化的思路，也就是每读一项就合并同类项，输出也是边输出边判断怎样可以字数最小。在作业三的时候就感觉优化打乱了整个代码的正确性，写起来很难受。
第二次作业优化也做得不是很好。一方面是没有想到很多优化的点 1-sin^2(x) = cos^2(x)，一方面是在用暴力的方法优化的时候发现了bug无法解决（在循环中remove一项），最后采取了一个较为简单的优化方法，至少完成了部分优化。
两次作业字符串处理都是运用的读到Poly，分成Term，再将Term进行读出数据。理论上我认为这个方法还可以，但是在第三次作业就出现了问题，Poly套Poly还是不太好解决的。最后在对于WrongFormat的识别还是有Bug，我认为是由于整个过程有一点太复杂了，没有处理好。
Bug
第一次作业在强侧和胡侧中都没有找到bug，但是可能对爆栈没有进行过多测试。第二次作业没有好好审题没有发现对系数10000的要求包含了等于条件。
前两次作业由于是从0开始构造，所以思路相对很清楚，所以很好的将复杂的地方拆分成很多小的部分，所以不是很容易出bug。
发现其他同学的bug
因为课程原因，我周日还有课程，所以我看其他同学程序的时间没有很充足。我一般都先丢到测评机里，自己看一看哪里比较复杂（比如很多if，或者代码看起来乱糟糟的），根据这个部分的功能自己手捏几组数据。并且把自己错的数据，临界条件试一试。但是很明显这个方法并不能看到很多同学的问题。相反，这个过程反而自己学到了很多。可能作业2我更偏向于看同学是怎么做的优化的，以及如何分的类。
第三次作业
UML
度量分析
行数
第三次作业分析
从度量可以看出来Term里的printSimple方法结构上比较复杂（他就出了BUG），并且PolyDiff类里有几个和字符串字符处理的类结构也较为复杂（比如changeBra这些），导致了在字符串化简的过程中的识别Poly里面的Poly出了BUG。还是哪里结构复杂哪里结构容易出问题。第三次作业问题很多。
1、由于相对类较多，所以在处理过程中会忘记一些细节，注释较少所以经常看自己代码不知道自己在干什么。
2、第一二次作业遗留问题在作业三没有解决。
3、第一二次作业对第三次作业扩展性较差，实际上自己基本都是重构了，但是没有放弃之前的结构，导致在书写过程中忘记自己对于某个方法到底写了没有，并且之前的结构会影响、束缚自己的思路。尤其在字符串处理过程中，很多方法在功能上有重叠。
4、优化没有处理好。主要是对括号的处理没有理清楚，不确定不同状态下括号的处理形式。
5、在WrongFormat处理的时候如果用异常应该会更好，应该会使程序结构更简单一点。
6、我是对Poly类既可以作为输入那个整的表达式，也可以代表子表达式。但是对于两个不同需求方法应该有区别，可能二者用继承关系分开来可能会更好。否则可能有的时候不确定自己要用什么方法。
7、自己想完成合并同类项的工作，并且写了一部分代码，但是发现好像复杂度很高自己不确定能不能写好就放弃了。有一部分代码应该没有卵用。。。
我的BUG
我的BUG来自printSimple字符串输出，在只有一项x+1的时候输出x1，就是由于if嵌套有点多没有理清思路；另一个就是对WrongFormat由于对字符串处理太复杂了导致出了问题。主要是没有理清哪一步会把有问题的格式剔除掉。我觉得这一部分是自己第三次作业没有设计好结构，另一方面是第1、2次作业设计不太具有扩展性。这两个都不是结构上的问题，主要都是逻辑复杂，自己没有想明白，导致的问题。
自己的测试机没想到还会在wrongFormat出问题，x+1可能是跑的时间有点短，没有发现。自己做测试没有着重测试WrongFormat的问题。
同学的BUG
一般都是丢测试机里，对错误输出自己稍微看一看原因在哪里，然后尽可能的保留最简单的错误序列丢上去，也算是帮同学找到问题的地方。一般也会看一下同学优化的程度，优化好的自己也会去看他的程序，测试的时候也会看是否会爆栈。如果优化不好可能就不会再看程序了。我发现同学的bug是在合并同类项对于符号的处理出现了问题，应该问题不大。
改进
1、一个是对类再进行一个区分，将最大的表达式继承 自表达式类。
2、加入异常来处理WrongFormat
3、对字符串处理还是应该放到其他类里面。
4、利用工厂模式完成一部分字符串创建Factor的过程。我可能想利用工厂模式传入Factor对应字符串，在工厂类里进行转化，也就是在工厂里完成对factor类型的判断。并且如果是Poly的话，应该再去调用字符串处理类的方法，如果是cos/sin的话，应该会再调用工厂模式进行创建。
5、第三次作业我对于括号的优化没有很好，合并同类项优化也没有完全完成。这两个应该再原有基础上比较好进行优化。对于更加复杂的三角函数可能会出现很多问题。
对比和心得体会
自己程序层次化并没有做到很好，整个层次我感觉很乱。
如果对factor进行封装会更好，而且可以引入一个类来完成手动测试的操作。
自己的主类写的好乱，有一些功能没有放权给其他的类。
优化做的差了很多，一个原因是自己想不到这么优化，另一个是自己优化后出的bug不好修改。
对于继承和接口的使用思路没有那么宽，感觉运用没有很灵活。
注释写的有一点点少，其实有的部分一两个字就可以提醒自己干了什么。
其实做的过程中感觉自己不断在思考什么叫做面向对象，又可以怎么去设计，但是很多时候没有落在笔头上，码程序的时候忘记了一部分导致写着写着就变成面向过程了，但总的来说感觉利用一两天去考虑怎么设计还是挺有帮助的。而且一些基础知识不是很牢固，对于继承和接口的使用还是感觉可以做的更好一点。对于不同的设计模式在经过第二次试验了解更多了，但是真正自己去使用总是不太敢用，或者目前没有发现他真正便捷的地方。
第二次作业感觉自己对于面向对象的了解更加深入了，而且设计的时候也可以很好地去完成。可能想的不是我怎么去做这件事情，而是我需要做些什么才可以完成这些事情。但是缺少思考整个任务需要我完成什么，导致主类写的很乱。
对于Bug还是自己不够细心。一两天的设计让自己最后没有很多debug时间，并且太依赖测评机没有很好的去读自己的代码。而且没有考虑程序的鲁棒性，导致问题很多。这应该是以后需要注意的地方。