OO 第一单元总结
第一次作业
要求：
本次作业仅要求实现简单多项式导函数的求解
思路：
1. 将多项式读入后先直接去除空白字符，再根据加减号分隔成项
2. 将项的系数和指数分别映射到Hashmap的key和value中，再遍历Hashmap进行规则求导
3. 将求导后的项进行合并同类项，正项提前等化简操作
类图
度量分析
说明：
本次作业我只设置了一个类，将所有的输入输出以及表达式的处理、求导全部放在一起，整个思想完全是面向过程，由于本次作业并不复杂，所以并没有带来太大的麻烦，但是程序分析来看模块复杂度和圈复杂度都过高了，对于之后程序的扩展很不利
hack & hacked
由于本次作业分类情况较少，因此在强测和互测中都没有找到bug
第二次作业
要求：
本次作业在第一次作业的基础上增加了三角函数的求导
思路：
1. 将多项式读入后与第一次相同进行分类
2. 将所有的项均处理为 a*sin(x)**b*cos(x)**c 格式，在此基础上进行格式化求导
3. 将所有的求导结果进行合并
4. 在合并过程中注意系数为0、1、-1；指数为0、1的情况，同时进行合并同类项，正项提前等操作进行结果的化简
类图
度量分析
说明：本次作业虽然增加了三角函数类和合法格式的判定，但总体来说跟第一次作业并没有太大的不同
因此，这也决定了我不思悔改地继续着面向过程的道路，直接导致了第三次作业的错误点极多
hack & hacked
本次作业在强测中挂了一个WF的判断，原因是正则表达式中对于合法空格的误操作
在互测中，由于某个字符串变量的初始化位置错误，被hacked较为惨烈
第三次作业
本次作业由于个人的时间原因、前两次代码的完全面向过程 (完全不可扩展）以及数据结构知识的匮乏，结果实在有些惨不忍睹......
要求
在前两次作业的基础上增加了嵌套求导的规则
思路
1. 将输入的多项式按加减号分割成项
2. 将项分割成不同的因子
3. 根据因子的种类实行不同的递归求导法则
4. 将导数输出
关于WF：
1. 首先通过replace方法判断是否有非法数据（包括非法空格），有则直接WF
2. 其次我对于WF的空格位置进行判断，如果没有问题，就删去所有的空格。判断方法：指数符号间的空格以及数字与数字之间的空格都比较容易去除，关键的是处在符号和数字之间的空格如何判断。我是通过枚举情况的方法，将空格两边的非空白字符不断提取，直到达到边界条件或者出现WF再进行return。缺点是因为有括号以及三角函数的影响，需要罗列的情况实在太多，稍有不慎就可能出现遗漏，因此将其放入后面的正则判断现在看来可能反而更加方便一些
3. 最后是关于整体的WF的判断，我依照评论区一位同学的做法即将sin\cos括号中的因子与表达式括号中的因子分别替换成不同的符号，先对替换后的整个表达式进行WF的判断，其次再对替换下来的三角函数内部的因子和表达式因子内部的表达式进行格式判断，这样就避免了正则表达式书写中自身调用自身的循环情况
4. 还有一些诸如指数大小限定等的WF我将其放在程序处理中判断
悲伤的第三次作业类图
一路飘红的度量分析
说明：
1. 本次作业构造了Expression（表达式）、Term（项）、Factor（因子）类，将表达式先用+、-分成项，再将项根据*分成不同的因子，不同因子根据不同的种类分别进行求导，求导后再进行汇总
2. 由于此次作业含有嵌套的情况，所以我使用了递归的方法进行求导，整体思路是按照递归下降的方法，又表达式到项再到因子。在具体实现过程中，三角函数中的部分直接放在因子求导中求导，表达式因子中的部分直接放在表达式求导中求导，虽然整体思路并不复杂（不涉及化简），但是实现起来确实需要仔细地思考每一种情况，否则输出的格式很有可能会WF
3. 由于时间关系，本次作业没有进行任何化简
4. 本次作业细节很多都没有处理好，比如输出结果中的括号以及正负号的位置，虽然看似微小的错误都导致了最后的翻车
关于hack与hacked方法
1. 在第一次作业中我使用一个基于python和shell脚本的测评机，但可能是因为生成数据的随机性太大，基本无法找出错误
2. 在第二次作业中我收集了自己在程序debug过程中出现的错误并仔细查看了1-2位同学的代码，主要是正则表达式以及过多条件判断等容易出错的地方，检查出来的也只是一些细节性的错误，没有普适性，可能相互hack只是手段吧，真正学习到优秀代码思想中的精髓才是意义所在
3. 第三次作业由于自己代码出了较大的偏差，分到其他同学的代码也出现了较多的错误，主要都是在与WF的过度判断和输出格式的WF上，比如sin和cos中的表达式因子没有嵌套上括号等
4. 总的来说，能进入互测得代码基本上还是差强人意的，有的可能会出现一些低级错误但这并不是我们所要关注的重点，我们在hack别人的同时应该注重于学习并提升自己，就第三次作业来说不少同学都有着比较精妙的化简方法和清晰的组织架构，这是很值得我学习的
应用对象模式重构
前两次作业如果说是因为还不熟悉所以仍然比较面向过程的话，第三次作业的确是个人原因。
由于本次作业周四晚上才开始动笔，之前也没有思考过如何构造，导致强测及其惨烈。大结构毫不OO，小bug层出不穷，这也与我之前在前两次作业中没有仔细研读同一room的其他拥有优秀架构的同学的代码有着极大的关系，虽然有了一些面向对象的思想，但总是怕付诸实践到代码中会出错，因此一次又一次地选择过程式编程。但现在看来这样的做法对自己毫无用处。痛定思痛，之后还是需要付出时间和精力。重构总是在所难免，但没有意义的重构除了浪费时间好像也别无他用。
在开启下次作业之前我可能还是需要深入面向对象思想，无论是封装、继承还是多态，先尽量使用在程序中，相信用多了应该就能慢慢理解其中的思想了吧。
对比和心得体会
从寒假的pre作业到现在每次作业的迭代，课程组花费了大量的时间和精力培养我们面向对象的思想，包括往届学长学姐的博客以及讨论区同学们的技术分享，我得到的资源其实已经很多，但是三次作业面向对象的思想我却丝毫没有应用的确是不应该的。希望之后自己能够多使用理论课上讲的方法，在学期末至少能给自己一个满意的答案吧。