一、作业分析
本单元作为OO这门课的第一单元，作业难度总体来说不是特别大，三次递进式的作业每一次的作业相较于上一次作业难度和处理的复杂度逐渐平滑上升。这一单元的学习主要是培养我们面向对象编程的良好意识，能够根据对象的性质和关系进行多层次的规划并进行归一化的管理。
1、Homework1
1.1 程序分析
UML分析
复杂度分析
代码行数分析
从UML类图中可以看出，这一次的作业我有了一定的面向对象的思想，能够单独分出一个项类，但是还没有完全将面向对象的思想贯彻，并没有将输入处理、主控、核心数据管理这个三个类完全分开，在第一次作业中我的输入处理和主控类是混在MainClass类里面，此时的我还带有一定的面向过程思想。
整体来看第一次作业的复杂度并不是很高，就是输出的toString方法耦合度比较高，这也是后面两次作业的通病。有一部分原因是因为在简化输出的时候用了不少的if-else判断，导致复杂度升高。
1.2 bug分析
在第一次作业的强测中我得了一百分，但是在互测阶段我被两个dalao揪出了一个bug，让我光荣的成为我屋首个被刀，也是最后一个被刀的人，导致当我看到我是我屋唯一一个被刀的人的时候心态有点爆炸。这个bug是因为我写的正则表达式有问题，导致+- x这种情况对于x的正负号判断错误。仔细分析一下出现bug的原因有两个：首先我的正则表达式是一个大正则，就是一行一二百个字符的那种，导致后续检查正则表达式的时候十分困难也极容易检查不出错误来，而且如果嵌套太多的化还可能造成表达式溢出的问题。意识到这个问题后，在后面两次作业中对于正则表达式的处理都是采用层次化正则的处理方式，简单易懂方便管理；第二个问题是我用正则处理表达式的时候把空格放进去一起处理了，导致正则里面多了很多\s，后面到底带*还是+就很难区别，这也就直接导致了bug的出现。吸取了教训后在后续作业中我都是判断Wrong Format后先去掉空格，再进行字符串的处理。
在第一次互测中我并没有找出同屋里别人的bug，一方面可能是第一次作业难度不高，大家对于一些易错点已经做了充足的测试，另一方面就是我当时只是自己构造了一部分样例，没有用到自动生成样例对拍器，导致找bug能力不足。不过在找bug的过程中我也读到了相当一部分优秀的代码，我也是在阅读了屋友优秀的代码之后就意识到了自己代码设计的缺陷，并加以修改。
1.3 心得与体会
第一次作业算是我上手java写的第一份具有一定规模、一定代码量的代码，也反应出一定的我写代码存在的问题，没有将原先面向过程编程的思想完全转变到面向对象编程，但也有了面向对象编程的意识，对于java中容器的概念和使用有了一定的了解。
2、Homework2
第二次作业在第一次作业的基础之上因子类增加了三角函数因子，同时引入乘法规则，复杂性进一步提升。
2.1 程序结构分析
UML分析
复杂度分析
代码行数分析
此次作业的复杂度有所提升，因此我的作业中耦合度高的方法增加了不少，尤其是在处理输入的时候所用的setFactor()、getFactor()以及输出和化简输出的simplifyTrigo()、toString()方法。代码长度大致均匀，Term项类会因为需要处理输出而略显臃肿。
对于此次作业我秉承了面向对象编程的思想，层次化进行设计也做得不错，但是还是有一些数据冗余，处理的不够简洁。另外，对于项的表达，我采用的是合并因子，最后写成a*x**b*sin(x)**c*cos(x)**d的形式进行处理，对于项的求导就直接手动求导求出来三个项，每项就直接根据原项的系数填数字就好了。这种处理方法可能需要写的代码量很少，但是会增加其他人阅读我代码的困难程度，最主要的是这种方法的可扩展性非常不好，假如说再增加几种因子，比如log，e**x这种函数，或者说像第三次作业那样加入嵌套规则，那么原项的因子会非常多而且不确定，手动求导就会显得非常麻烦，而且求出来的项数也会集合倍数增加，因此这种方法只适合这种因子数少的情况，像第三次作业根本不适用，导致我在第三次作业花费了不少时间研究对项的处理。
第二次作业的优化难度要比第一次高上不少，最主要的原因是引入了三角函数，像a*sin(x)**2+b*cos(x)**2这种都可以化简，我是对a*sin(x)**b*cos(x)**(c+2)+a*sin(x)**(b+2)*cos(x)**c这种形式进行了递归化简，最后强测反馈的化简效果不是特别好，可能是因为算法原因，后来在周三的研讨课上听了同学的化简思路后有所启发，是我的化简程度还不够。
2.2 bug分析
此次作业的强测我错了一个点，这个点是一个Wrong Format，然而我并没有判断出来，原因是真的让人气，我在处理空白字符的时候直接用的\s图省事，但是作业中合法的空白字符就只有空格和制表符，其他的空白字符是非法字符，强测的那个点正好是一个非空格和制表符的空白字符，导致我失去了宝贵的5分强测分。这次出现的bug也是对我的一次提醒，要仔细阅读指导书上的说明，不能因为图省事无故失分。
在互测中我没有被hack失分，我hack了三个人，其中两个人是因为对x**-10000这个数据判断成了Wrong Format，还有一个人对于-x这个数据输出有问题，没有把-1后面的1输出出来。
2.3 心得与体会
此次的作业我基本上完成了面向对象的层次化架构，但是做的还不够充分，仍有部分冗余。另外我明白了仔细读指导书的重要性，仔细研读指导书有时候也会给让你想出一个新的解决方法。
3、Homework3
第三次作业在第二次作业的基础上因子类增加了表达式，同时引入了嵌套规则，复杂度大大提升。
3.1 程序结构分析
UML分析
复杂度分析
代码行数分析
这次的作业相较于上次作业最大的不同就是引入了嵌套规则，而且因子里面可以是表达式。表达式的嵌套就直接导致这次作业不能够用正则表达式直接对表达式进行解析，从而部分输入函数和判断WF的函数复杂度飙升。失去了正则表达式这个利器之后我花费了很长时间来思考怎么对输入进行处理，最后选择了递归调用各个因子的输入处理函数对表达式进行处理。在输出方面选择的是正常的输出套路，递归调用各个因子类的toString方法，导致表达式输出部分耦合度也比较高。
此次作业的化简也是一个难点，我自己尝试着写了一些深度优化，复杂度很高而且优化的效果并不是很好，可能还是化简思维方式的问题。周三的研讨课上听了同学的化简思路，我发现我的问题就是思路只局限在输出地方的化简，其实在输入处理的时候就完全可以进行化简，比如将只包含一个因子的多项式转换成一个因子等等，这都是很好的化简思路。
3.2 bug分析
在此次的强测和互测中都没有被发现bug，但是我在自己debug的时候发现了不少bug，比如由于此次作业多采用递归调用，多层的嵌套，如((((x))))这一类的处理可能会超时，比如我一开始十一二层的调用就超时了，这是因为我在化简输出的时候多次调用toString方法，而toString方法也是递归调用，过多的嵌套就导致了超时。后来我在每一个因子类定义了一个string属性并设置读取方法，他是用于存放因子的toString方法返回值，如果说第一次读取string是null的话，就将string赋值toString方法的返回值，这样就不会每次需要toString还要跑去调用了，节省大量时间。
在互测中我发现了别人的一个小bug，他对于0*x+sin(x)这种数据输出处理不当，直接输出的0cos(x)，我想可能是化简输出的时候除了问题。
3.3 心得与体会
随着作业难度和复杂度逐渐升高，我们写的代码量、思考的时间都在增加，我们不能依赖于仅仅一种方法或者处理方式，比如不能只依赖正则处理输入，只用一种容器等等，我们需要多学几种方式，以备一种方法不能用的时候可以有其他替代方法。另外就是写代码之前要好好架构，否则可能导致写的过程中发现没法解决的问题而推倒重构。
二、对象创建模式的应用
第二次实验我们学习了工厂模式的使用，说实在的在当时可能因为初学工厂模式，我还不能完全感受到这种对象创建模式的优越性，之后通过同学的介绍以及自己查阅资料并动手实践，我逐渐意识到工厂模式的优势。仔细分析，作业中在构造因子的时候可以用工厂模式构造，这样构造因子部分就不会过于臃肿，代码更加简洁，思路更加清晰。
三、总结
从第一周作业的总体情况来看，基本上贯彻了面向对象编程的思想，但是对于层次化设计的应用不太理想，没有用过接口实现抽象层次，另外还缺乏工厂模式等创造模式的训练。在设计代码的时候多注意降低模块之间的耦合性，保证代码的简洁性和可阅读性。在bug方面一定要做到课下多测试，才能达到课上不出错的结果，课下自主测试的时候要多构造样例，尤其是边缘样例。再有就是多多借鉴别人优秀的代码，学习别人写的代码思路，从中找到自己的不足与差距，从而进一步提升自己写代码的水平。
最后我想谢谢在我学习OO的过程中给予我非常大帮助的同学以及助教们，在我思路受阻的时候一起学习一起交流。愿在之后的OO学习之路上继续一起前行。