Main类主要进行的是对多项式的解析以及对因子括号的处理，以及输入输出和对原始的函数及多项式的表达式进行预处理，预处理首先是处理空白字符，系那个空白字符通过replaceall函数全部去除，然后是处理连续符号的的情况，将连续的符号化简为单个符号，最后就是将指数函数中的exp替换为E，求导因子中的dx替换为D，以便后续对多项式的解析，避免因为x的识别问题而导致出错

Expression类主要功能是存储表达式因子并进行加、减、乘、乘方以及求导的计算

Value与Key是一组，主要是处理变量及其指数因子

Item类就是主要存储项的，将原表达式变成由多个项相加的形式，将经过预处理后的多项式按加号拆分（括号及函数中的加号不计）成项，再将项存入Item类中

Func类主要是存储函数因子，将多项式中的函数相关因子识别出来整体存放到Func类中以便后续处理，对函数的识别主要是通过正则表达式来实现的

类图

经过三次迭代作业后，类图如下：

复杂度分析

类复杂度

方法复杂度

代码规模

架构设计

因为在完成第一次作业时我对课程实验代码所用的递归下降代码等理解不到位，所以在完成第一次作业时主要还是用的二叉树来存储数据的，就没有完全采用实验及训练中给出的代码，这也导致我在后续进行作业的迭代时困难较多。

第一次作业

我在完成第一次作业时的整体思路是用二叉树来存储因子以及运算符号，整体上首先以最外层的加号拆分，将预处理后的多项式拆分，加号作为父节点，加号两边的表达式作为左右子节点，若子节点最外层还有加号则继续上述操作；若不含，则说明以及将原来的多项式按加号拆分成了一个个项，这些项的最外层就只可能含括号、乘号、单独的因子如常数或单个变量和乘方符号^，如果此时的因子最外层按照乘号-乘方符号的顺序进行拆分，同样是以符号作为父节点，符号两侧作为子节点，拆分完毕后的因子最外层就不再含运算符号；此时，若作为子节点的因子最外层含括号，则将括号去除，将括号内的表达式按照最开始处理多项式的方式继续处理，直至将多项式拆分为一个个不含任何运算符号或括号的因子，示例如图所示：

后续作业也是在第一次作业的框架下进行迭代改进的

第二次作业

第二次作业是在第一次作业的基础上新增了多层嵌套括号，自定义函数和指数函数的化简，在第一次作业中，我的框架已经实现了对多层嵌套括号的化简，因此第二次作业中只需新增自定义函数以及指数函数的化简即可，因为函数中参数可能也是表达式的形式，我就将函数进行一个类似于运算符号的处理，将函数内的表达式按照第一次作业处理多项式的方法处理即可，同时，函数符号的拆分解析的优先级和括号类似，只有当当前表达式最外层只含函数符号时才对函数进行解析；对函数符号的识别是通过正则表达式来完成的，在处理指数函数时，因为指数函数的exp中的x可能与作为变量的x混淆从而导致错误，于是我在预处理时就将exp整体替换为E从而规避这个问题。虽然整体思路还是比较清晰，但因为我第一次作业构建的框架在可扩展性上不太好，所以实现起来比较困难，最后也是在第一次作业的框架上做了一些改动，才完成了作业的迭代

第三次作业

第三次作业与第二次作业相比新增的是函数在定义时可调用其他已经定义的函数还有求导因子的化简，这一次的迭代相较于第一次到第二次作业的迭代跨度较小，且经过第二次作业的调整，整体架构的可扩展性也有所提升，因此第三次作业的迭代整体实现起来并没遇到太大的困难，其中求导因子的dx与exp预处理相同，将dx整体替换为D后再将多项式进行解析

总体来说，我的框架能够基本完成作业要求且具有一定的可扩展性，若还有迭代作业应该也能继续扩展。但我的框架也有很多不足，我的框架功能比较混乱，在几次作业的不断调整中，原本应当只用于存储表达式的Expression类也用于计算，而且对于多项式的解析是在Main类中进行的，这使得我的代码可读性较低。后续若还有迭代，我应该试着将这些功能单独调整出来，使得不同功能相互分隔开，让每个类都承担单一的功能，便于代码的阅读和维护，比如后续若有新增三角函数得迭代任务，那我应该在我的正则表达式中加入对于三角函数的识别和判断，同时在解析和运算多项式时加入三角函数的情况。

程序bug

第一次作业

在第一次作业中，我的代码的bug主要体现在预处理中，首先是对于空白字符的处理存在问题，刚开始时，我只处理了空格而忽略了其他的空白字符，在构建样例时也忽略了其他空白字符，导致我在中测时就产生了很多错误，然后是对于连续符号处理不到位，不能处理多个连续符号的出现，好在后续解决完这些问题后互测和强测都没有什么问题

第二次作业

第二次作业与第一次作业相比跨度很大，同时代码的问题也比较多，比较主要的bug主要在于对函数的识别中，一开始我是通过逗号来对函数内参数进行分离的，但忘记考虑了嵌套函数的情况，导致逗号识别会把参数内函数的参数一起识别，于是我又对函数括号的位置加了一个判断，只识别最外层括号中的逗号；还有一个bug实在强测中发现的，就是我的指数全部是的int类型，遇到比较大的指数时就会出错，之后我就把int全部改为Biginteger类型，但出现的问题是程序运行时间过长，我推测是在改Biginteger时所用的一些方法让程序运行时间过长，然后我又把类型全部改为long，才把这个bug给解决掉

第三次作业

第三次作业因为整体难度并不算太大，且有了第二次作业的基础，就没出现太大问题，唯一一处问题是在漏掉了求导因子的括号导致在因子为表达式时可能出现运算顺序错误的情况，这个问题在中测中并没有发现，是后来借助同学的测评机才得以发现，避免了强测时大量失分

互测体会

在互测中，我发现其他同学代码的bug主要还是借助其他同学的测评机，通过大量的数据进行测评往往能找出代码中存在的问题，而我自己构建的数据往往不够全面，难以达到全面测评的效果，互测还是很大程度上体现了测评及的重要性

优化

第一次

第一次输出结果的主要优化点在于把字符串开头的负号换到式子中成为减号，如x-1比-x+1更短

第二次

第二次我因为在调整框架时花费的时间太多，没来得及进行结果优化，我认为主要的优化点还是在于指数函数中表达式的公因式的提取上，时间上的优化就是上文提到过的将Biginteger类型转化为long

第三次

因为第二次作业时代码就没有优化，所以第三次也没有进行优化，但我感觉结果的主要优化方向应该还是在指数函数内部表达式的优化上

心得体会

虽然这是OO的第一单元，但我认为其难度也很大，与之前学过的OOpre课程的难度完全不在一个层次，具有很大的挑战性。OO课程中的互测机制和研讨课机制对我来说也是一次全新的体验，互测不仅仅是去发现其他同学代码中存在的问题，也是通过其他同学存在的问题检查自己是否存在相应的问题，而研讨课则是提供了同学之间面对面交流的一个机会，可以去学习其他同学优秀的结构框架以及优化思路。在与其他同学的交流中我受益匪浅，不仅学习了更加清晰的框架和思路，也通过和同学的交流找出来我代码中存在的问题以及相应的解决方法。总之，经过第一单元的学习，我对OO课程有了一个基本的了解，对于面向对象编程也有了一个更深的认识，自己编程的能力也得到了相应的提高。

未来方向

我认为在优化方面可以给一些相应的提示，否则自己盲目优化很难达到预期效果，且过度优化也有可能让原本正确的代码出现bug，其次是在互测方面可以适当增加一些代价，便于更好的发现代码中可能存在的问题并进行hack，此外，我觉得还可以在第一单元适当增加一些对于Java基础知识的讲解，因为在没学过OOpre或是对基础知识有些遗忘的情况下直接开始第一单元的学习难度有些大，并且无法很好的理解指导书或实验中给出的代码，适应起来难度较大