oo前三次作业总结

oo前三次作业总结

前言

oo前三次作业由简到难渐进的实现了一个表达式求导。这篇总结将从分析程序结构，分析自己程序的bug，分析自己发现别人bug的策略以及Applying Creational Pattern四个方面出发，分析总结前三次作业中的优点与缺点，做阶段性总结。

基于度量分析自己的程序结构

复杂度分析

第一次作业

可以看到Poly类的toString方法iv(G)与v(G)值很高，主要原因是在第一次作业中没有采用Term设计一个toString方法而后在Poly类调用这个方法的结构，而是在Poly类toString方法完成所有的字符串处理工作，导致Poly类toString方法需要大量访问Term类的base和index域。

第二次作业中的主类里的toTerm方法（其实第二次作业把表达式处理放进了主类里，所以会出现toPoly，toTerm方法，还带着浓浓的面向过程风）因为多次调用了BigInteger类的方法（进行底数指数运算）所以iv(G)较大，同时对各捕获组采用了if结构，导致v(G)(循环复杂度)较大。

第三次作业中input类里的几个方法（toCos，toFactot，toPower，toSin）的e(G)较大，方法较臃肿，略显病态。

类图分析

由上至下依次为第一至第三次作业的类图分析，可以看出前两次作业还是面向过程式的编程方法，仅仅针对当次作业给出的问题去解决，没有利用java的继承与接口特性，可扩展性几乎为零。第三次作业虽然利用了继承，但是由于没有领悟指导书给出的方法建议（不会实现），采用了一个较为复杂的结构，可扩展性依旧不好。

Bug分析

三次作业中第一次第二次作业存在bug，主要集中在输入处理上，即在格式识别上出现问题，我认为与程序架构无关，主要是细节问题。

第一次作业

第一次作业中忽略了指导书中空白字符仅仅闲鱼\t与空格，在正则表达式中用\s去匹配空白符导致某些特殊的空白符没有判断为WF。

第二次作业

第二次作业中错误的在[]用‘ ’表示空格字符，实际上不需要加单引号，导致在输入有’的情况下无法判定为WF。

分析他人代码bug采用的策略

我认为这三次作业可能出现的bug主要分为两种情况：输入的格式判断错误和对表达式求导错误。

针对输入格式判断错误，我在测试自己程序时保留了多种我认为可能出错的情况对互测屋内的人进行测试。

针对表达式求导错误，我把表达式分为几种类型（诸如嵌套，常数等）对每种不同类型对互测屋内的人进行测试。

限于时间和精力的原因，我并没有仔细阅读研究互测屋内其他同学的代码架构，因而也没有针对架构生成测试样例。

Applying Creational Pattern

我的第三次作业因为没有理解透彻指导书中给出的结构，采用了一个可扩展性不高的结构。其主要思想是表达式，项，因子三层结构，因子扩展出了常数，幂函数，sin，cos以及表达式因子这些子类。项形成表达式默认使用了加法（减法可以看做因子是负数的加法），因子形成项默认使用乘法，在sin，cos以及表达式因子中默认使用了嵌套，这种把函数组合规则按照默认形式隐藏于表达式组成的方法虽然可以完成本次作业，但如果扩展除法等其他函数组成规则则无从下手。通过阅读互测屋内其他同学的代码我了解了指导书上架构的具体实现。

总结

前三次作业逐步的将我们的编程思维从面向过程转向面向对象，希望以后能够尽快调整自己的思维方式，用更面向对象的方式思考解决问题。