OO面向对象第一单元总结
一.三次作业代码分析。
1.第一次作业
第一次作业作业是完全简单幂函数的求导。难度较低，但是对于刚刚入门JAVA的我来说，对于类与对象的理解与应用还不是很熟练，以及怎么构建出一个层次，以及层级间如何进行数据交互是一个头痛的问题。
最终经过不断考量，勉强做出一个我自己比较满意的结构：Main函数入口，构建表达式类Poly，先去除多余空格与符号，然后依据＋-号来进行项的分割，构建item类，提取其系数和指数，在Poly类构建一个 Arraylist 来储存每一个item的系数和指数，求导法则较为简单，只需要根据系数和指数进行更改即可，然后将更改后的系数和指数返回得到新的Arraylist，再合并同类项，构建 toString 方法，生成表达式输出，基本上就完成了格式正确情况下的求导正确性部分了。
WF格式的判断对于新手来说的确不友好，大串正则不仅容易出错还容易爆栈，但是惭愧的是，第一次作业我还是使用了大正则，以至于再过了中测后，自己还是找到了不少bug。爆栈的问题也是经过大佬指点，知道贪婪模式和懒惰模式，在结尾加一个'+'号就解决作业了中的爆栈问题。
类图：
度量分析：
2.第二次作业
第二次作业相比第一次作业增加了sin,cos和连乘，格式判断也更为复杂。但是大体思路没有变化，我仍然采用第一次作业的结构和思路，虽然完成地比较顺利，但是基本没有可拓展性，导致我第三次作业推倒重来。
类图：
度量图：
3.第三次作业
第三次作业难点在于嵌套和表达式因子，并且没有很鲜明的几个特征值来直接进行求导，所以前两次作业的架构完全不行，于是我开始了灾难的重构。但是由于对接口和继承的用法没有理解到位，所以在构建的时候也没有将之运用在程序之中。
本次作业的输入格式分析和第一二次完全不同，因为带有嵌套因子和表达式因子。所以这次作业，我先进行了表达式预处理，排除掉一些错误情况，然后在递归求导的过程中，对每一个非表达式因子进行合法性判断，嵌套因子和表达式因子则拆开之后继续递归调用poly的depart()方法进行拆项求导。并且由于递归的使用，为了追求正确性，我放弃了优化。
类图：
度量图：
PS：此外，由于刚接触OO这门课程，每一次作业对我来说都是不小的挑战。于是我采用了上学期祭祖写P7的方法，先在脑子里思考好大部分情况，写一个简要的设计文档，提醒自己该干嘛，该怎么写，有哪些情况要考虑清楚，这样不仅会减少出bug的概率，也会在写代码的时候事半功倍，这也是我为什么周六或者周日才开始编码的原因。由于第一二次作业思路较为简单，在此我只贴出自己第三次作业的"设计文档": (由于是一个思路草稿，写得比较粗糙，若有错误和遗漏（肯定有）
二.BUG分析
第一次作业
（1）在公测时候没有处理好WrongFormat的判断，导致爆栈和错误输出。
(2) 没有考虑到空白字符只能是/t和<space>
(3) 在求导后，删除系数为0项后没有考虑到当每一项都为0的时候也要输出一个0
第二次作业
（1）在删除系数为1的时候直接采用了replaceAll方法，导致可能会有系数为11或者指数为-1的时候省略导致出错。
第三次作业
(1)WrongFormat的复杂性没有考虑全以及手抖出现的错误，导致公测过得比较艰辛。
(2)由于进行嵌套因子检查的时候，出现了数组越界访问导致sin(-1)此类的数据给判了WrongFormat。
三.互测攻略
这三次作业，我每一次都是将每个人的src放在一个src不同的包中，先大致浏览一下代码，然后一个一个进行手动测试，测试的数据是自己课下以及在互测阶段出过bug的数据、自己构想的一些边界数据和室友大佬提供的一些测试样例。虽然效率较低，但是也还是成功地hack到了一些同学（抱歉）。
四.反思与总结
1.第三次作业中我并没有处理好sin(--1)或者sin(---1)此类数据，因为我在简化字符串的时候把多个符号合并为了一个，导致不能检测到此类错误，当互测时候意识到这一点的时候，发现想更正已经是难上加难，这说明我的架构还有待优化。
