OO第一单元总结

OO第一单元总结

一、基于度量分析结构

第一次作业

类图：

 

 

 第一次作业我将其分成Main、Expression、Term三类，Expression用于处理字符串并将各个项用Hashmap存储起来，Term类用于对各个项进行求导，逻辑较为简单

代码复杂度分析：

 

 

 

 

 我们可以从复杂度分析中清楚地看到，在类别上，代码的核心部分保存在Expression类中；在方法运用上，代码的核心部分则在对项的切割和把项的求导结果转换为字符串上。代码的分散性不够好，集中性较强。

第二、三次作业

由于第二、三次作业的要求和整体代码极为相似，这里即以第三次作业代码为例分析。第二、三次作业与第一次作业相比，显然有了翻天覆地的变化，第一次作业以指数为关键字建立Hashmap的方法完全不适用，因此对代码进行了重构。

类图：

 

 这里我采取的策略是先建立各个因子（除了表达式因子）类并赋予相应的求导方法，同样仍然在Expression类中对字符串进行正则匹配处理，不断重复利用乘法求导法则和递归压栈的方法保存每一个项（或者表达式因子）的求导结果，并注意细节方法的处理，会很好解决问题且思路简单。

代码复杂度：

 

 

 

 

 然而我在代码功能模块化处理上做得很不好，因为这种方法每次执行一段功能需要的变量很多，不适合将部分相同功能代码提取分割出来，故我们能看到这种方法主要还是面向过程方法的体现。在接下来的学习过程中还是希望自己多用面向对象的方法去处理问题。

二、Bug分析

这三次作业很遗憾的是，每次都有被找出bug，但更遗憾的是，每次bug都在正则表达式处理上。

第一次作业由于没有考虑到 + + + 8的情况，可能会被我分割成++与+8的情形，在正则表达式最前面再加上一个（\\s|\\t）?就解决了，此bug过了强侧但被互测找出

第二次作业由于在匹配x**2这种类型的时候没有考虑到**与2必须同时出现或同时不出现，在匹配**的时候将**后的？删掉就解决了，此bug过了强侧但被互测找出

第三次作业由于指数不能大于50，于是我对正则表达式进行了相应修改，指数匹配部分变成了（[1-4]?[1-9]|50）但根据正则表达式的规则在遇到50时优先只匹配5，改成（50|[1-4]?[1-9]）便解决了，此bug互测未找出但被强测找出

三、找bug策略

其实找bug无非就是在代码人没想到的点去寻找错误，这时不妨想一些边界数据、多层嵌套数据和难以想到的奇葩格式数据，就能找到代码中细节上的一些错误。

四、重构经历总结

第一次作业和第二、三次的作业思路是完全不同的，因此我进行了重构。原代码中，我将表达式以项先切割好存在Hashmap中，再在Hashmap中求导输出；新代码中，因为要处理括号问题，正则表达式不能精准地匹配括号，因此将每项提取出来就非常困难，于是我便处理边求导，设定一个原函数字符串和导函数字符串，根据后面匹配的项不断进行乘法法则求导，并在处理函数中调用递归以解决括号问题。

五、心得体会

在第一单元的实践中感受到在解决大问题的时候不妨将其一步步细化，化整为零，从底层慢慢搭到顶层。与此同时，调用和完善相关的算法，想好思路，便能简单解决复杂问题。

另外，我也体会到，在完善代码过程中，需要有足够大量的数据测试，才能保证程序的正确性，才能知道一些细节上的错误，并去修复它们。