oo第一单元的作业以多项式求导为主题，考察处理字符串的一系列操作，涉及正则表达式、集合类等重要知识。递进式的三次作业，使得大家的面向对象编程能力、debug能力、设计与架构能力得到了锻炼，对面向对象编程的思想内涵也有了越来越深刻的理解。
一、第一次作业
1、思路总结
第一次作业的内容是简单多项式的求导，输入的表达式字符串由+或-连接若干项构成。我的思路是对输入字符串进行拆分，以+或-将多项式拆分成多个项。再对每个项进行识别，分析它属于哪一类的项。我设置了一个Poly类，代表每个项，内含求导和输出方法。
2、设计
UML图如下：
由于本次是我第一次正式地进行面向对象编程，相关的经验基本没有，导致我的设计基本上还是面向过程化，类的架构也很不合理。
3、度量分析
方法度量结果如下：
类度量结果如下：
从度量结果可以看出代码圈复杂度较大，方法过长且内容复杂，难以维护与调试。改善方法：合理构造类与方法，明确每个对象，方法的功能应该更加清晰，且每个方法不能过长。并且我的本次作业缺乏面向对象思想，类的继承、抽象类等面向对象常用构造方法都没有涉及。
4、BUG情况
本次作业没有在强测和互测中发现bug。不过在中测时，由于粗心大意，导致我的一个正则表达式中少了一个加号，这让我花费了两天的时间进行了无意义的查找与思索。痛定思痛，以后写代码的时候一定要格外认真，在debug的时候一定要先反复地检查自己的代码，看看是否存在码字上的失误。
二、第二次作业
1、思路总结
本次作业在第一次作业之上有所升级，主要是项中增加了sin(x)、cos(x)两个因子，这在一定程度上增加了分析的复杂程度。但是这并没有带来本质上的难度提升，一些地方可以利用第一次作业的老代码。思路与第一次作业大致相符，需要修改的地方主要是对项的识别，要考虑sin(x)、cos(x)及与其他因子相组合的情况。
2、设计
UML图如下
这次作业的类的架构较上次作业而言有所进步。对于一些特定的功能，如对输入字符串进行空白符合法判断、字符合法判断等操作，我将其从main方法中抽取出来，分别放到一个类中。这使得main方法结构更加清晰，代码可读性也更高。
3、度量分析
方法度量结果如下：
类度量结果如下：
本次作业的代码圈复杂度有所改善，但是仍没有利用继承结构。也许是因为本次作业还不需要用到，但这反映了我面向对象思维还有待继续锻炼。
4、BUG情况
本次作业在强测中发现两个bug，在互测中被成功hack3次。经bug修复后，发现这些bug为同质bug，出现的问题在于优化输出过程中，仅仅简单粗暴地删除所有“1*”子字符串导致输出出现问题。今后在设计中要保持清醒的头脑，考虑地更加细致，思考地更加全面，避免此类问题的发生。
三、第三次作业
1、思路总结
第三次作业在第二次作业的基础上，难度有了很大的提升。主要在于嵌套规则的引入，表达式也可以作为因子出现，这大大增加了设计的难度，对于我来说的确是个不小的挑战。我在本次作业的设计中，主要思路是将类进行嵌套引用，而每个类都内置求导方法，在求导方法中引用其他类：表达式类（多项式函数类）中引用表达式类、乘函数类、三角函数类等，出发点是：表达式是由+、-连接若干项构成，而项分为乘积项（由*连接若干因子）、表达式项（单个表达式因子）、三角函数项（单个三角函数因子）等；乘函数类中引用表达式类、三角函数类等……除了最基础的x和常数，每个类都需要一个识别方法，判断其内部的函数属于哪种类型，于是它们都继承了Identify类，其中包含identify方法。
2、设计
UML图如下：
从图中可以看出一些类继承了公共父类Identify，这有利于整体的结构清晰、减少代码的重复。
3、度量分析
方法度量结果如下：
类度量结果如下：
本次作业代码圈复杂度较低，部分类内聚合度较小。总体而言较前两次作业有所提升，不过还需要在继承与抽象方法上寻求进一步的突破。
4、BUG情况
本次作业并未在强测及互测中发现bug。不过在代码完成后的debug过程中，我前前后后发现了将近20处bug，写代码与debug时间将近1:1。这说明我在将设计转化成代码的过程中，思路并不是很严谨，考虑不够细致周全。或者说在设计的过程中应该更加细致，将每个细节都尽可能地考虑到，不要将思考的压力更多地分配给写代码以及debug的过程中去。