第一次作业

类图：

 

复杂度：

　　圈复杂度的问题一直困扰着这三次作业，主要体现在求导方法中先判断符号导致出现过多判断语句，应该将整理符号放在一个新的类中处理。

第一次作业由于对面向对象的思维有些不理解，只创建了两个类，一个Main函数处理输入和输出，一个Poly类负责判断表达式合法性并求导。由于未考虑到超过32位数字的存在，导致我未能通过强测的半数内容，后来在Poly类中的求导阶段将数据的判断改成了BigInteger，顺利通过了强测的所有测试点。这个bug的修复只需修改几个方法的数据类型转换并用到BigInteger类的一些函数。当然，强测并未能测出我对一些\t类型的字符判断，比如说\f，这个问题我注意到了并在第二次作业中进行了修改。

由于强测分数过低没能进入互测环节，这次的测试用例大部分都在代码的格式问题上，就不再赘述。

第二次作业

类图：

复杂度：

第二次作业相比第一次作业多了sin和cos函数的求导，吸取了上次的经验教训，这次我将输入单独写入一个类，然后单独写了一个求导类，通过poly类调用，类图如上，缺点就是每个类的功能不够专一，然后类的相互调用有点多。

出现的bug主要在优化上，首先是0的优化没有做好，这里我将求导类中的symbol方法修改后解决了问题。另一个bug出现在cos函数的求导方法上，有个地方漏写了sin(x)，导致了错误。这些bug都不是结构的问题，是在程序写完后没能够构造完备的测试集导致的问题。

在互测环节，我主要针对乘积项的求导进行了检查，在代码检查上，我着重看的是代码在求导类中，项的拆解和结合，所以我设计的测试用例是多种不同的项的乘积之和。

第三次作业

类图：

复杂度：

　　

　　判断格式错误中的空格错误需要大量判断条件和判断语句，导致设计复杂度急剧上升，需要留意。

　　这次作业我把注意力放在类的专能化上，将判断合法性从input handler中剥离，然后将表达式的分解单独放到一类。这样做的优点是条理清晰，便于debug，缺点在于没有使用继承导致一个类的方法过多而不得不将求导类中的一些方法单建一类放置。

这次我的bug主要出现在0的优化以及一些格式判断上。问题出在求导类和Judge类中。犯了上次的错误，这次要格外注意。

互测中，我这次的测试用例着重考察代码中对于括号的处理，通过多重括号的嵌套，观察程序能否将括号内的所有信息抓取出来，从测试结果来看很多人的括号内的内容抓取都出现了问题，主要体现在符号错误方面。

三次作业的分析

在第一次作业的时候，由于表达式较为简单，可以使用正则表达式直接判断合法性，但是随着难度的加大，一个正则表达式的判断方法明显不能满足要求，于是我采取了拆解表达式分项判断的方法。后来明白我用的方法类似于递归下降。首先我将表达式中的不合法空格与不合法字符进行了判断，然后删去所有空格，将表达式拆成项，再将项拆成因子，对每个因子进行正则表达式的判断。在求导阶段，我将项传入求导函数中，拆解成因子，再逐因子求导、拼接，最后连接起来就达到了求导后的结果。接下来再处理符号问题。由于求导的过程未使用继承导致程序看起来很复杂，这是我需要改进的地方。

　　第三次作业应该采用的是工厂模式创建接口，但是我采用的是逐个列出方法的做法，导致了程序的复杂度和代码量的激增，在这点我需要多了解面向对象的思维方法，争取在下个单元做出改进。

张德法