BUAA OO U1

[23060101-尹馨平]

架构

hw1：

在完成hw1的时候，我对表达式进行了解析——即任何表达式都可以理解为两个Expr通过一个Operator连接构成。因此对输入表达式的解析思路就是通过递归识别Operator左右两边的Operator，按照表达式应有的运算顺序将表达式依次拆成最终的Operator组和Factor组。再对解析好的表达式重组，获得最后的结果。之所以使用后缀表达式，是因为这种形式的表达式运算顺序是绝对确定的，不需要括号和运算优先级进行额外的运算顺序指定。然后再根据解析出来的Operator对其左右两边的表达式进行运算。运算方法就是将表达式合并同类项之后，将其抽象成x的不同次幂及其系数的积的和，用Hushmap对表达式的各个项进行存储，key为x的指数，value为x的系数。然后四种运算方式都通过系数和指数操作，并合并同类项。最后进行输出。

hw2：

hw2在hw1的基础上增加了两种函数因子以及嵌套括号的处理，而嵌套括号在hw1中就已经能完成处理。对于自定义函数的处理方式是建立一个自定义函数类，在类中设置替换方法，将表达式中的函数名视作一个优先级更高的多元或单元Operator，然后在类的方法中完成函数体的转化（转化为后缀表达式）以及函数因子的替换，最后将替换后的表达式输出到原本的表达式树中。对于指数函数，其前期处理思路和自定义函数一样，将exp作为Operator提取。因为指数函数的计算方法和普通的常数以及变量项不同，因此新增系数类，exp系数类，将原本为integer类型的系数改为系数类。系数类将系数分为常数项和指数函数项，方法上按常数项和指数函数项分别重制系数类的四则运算方法。其中常数项就按照普通的运算规则来算，而指数函数项因为自带指数和系数，在exp系数类中再次按照其自己的系数和指数重置exp系数的运算方法。最后输出成结果表达式。

hw3:

在hw2的基础上新增求导因子和嵌套调用自定义函数。嵌套调用函数再hw2中就已经解决了。而求导因子的处理方式和hw2中的两个函数一样，先将求导因子作为一个Operator提取。因为求导因子的存在，在代码架构上去掉了表达式树类和节点类，转而在遍历后缀表达式的过程中，读取到Operator就直接按照其操作数的数量进行弹出运算，随后直接整个表达式压入栈顶，以简化操作流程。在Expr类中新增getDx方法为求导方法，而对表达式的求导的过程经过分析，可以总结为对表达式中每一项求导然后相加，而每一项的求导结果可以总结为系数的导数*x^n+系数*n*x^(n-1)。因此直接遍历求导因子中的每一项，其中系数的导数就是系数项的导数，因为常数项的导数为0，所以系数的导数其实就是不同次幂的指数函数的导数相加。就这样将求导因子中的表达求导然后相加再输出便能得到求导后的表达式，最后压入栈进行下一次操作。

类图如下：

 

bug分析：

在写hw1和hw2的时候，大概是因为架构如此，遇到的很多bug都跟符号相关，在转化为后缀表达式的途中或是在表达式树的输出过程中因为处理不当而产生了歧义。但是因为没能及时交上作业，错过了系统的测评，只能通过给予的输出样例进行比对。hw3终于赶在末尾通过了所有基础样例的测试，但强测死的很惨，并且没有达到互测标准。经过强测数据的样例对比，发现本来的程序中没有考虑到多个加减运算符连续出现时的处理情况，导致程序直接崩溃。还有我自己发现的指数函数项位合并同类项等问题...只可惜错过了互测机会，而且没有余力再自己搭一个测评机了。

 

方法复杂度

类复杂度

SuffixExpression的复杂度确实高的离谱了，因为类中的Solve方法在写法上有纰漏，而后续我也想到了在写法上更加面向对象的优化方案，只是来不及实现了。

 

测试策略和优化

测试策略：因为整个程序写的太过艰难，并没有很好的测试策略，我所做的只有将网站上的测试样例输入输出，看到没问题之后就上交了。

优化：其实过程中很多方法还是按照面向过程写的，对继承接口等用法更是完全不熟悉没有用过，还有之前提到的bug，合并同类项等问题...都是可以继续优化的点...

 

心得体会

其实我并没有想到这次我能在第三次作业的末尾，在朋友的帮助下最后交上一次能通过基础样例测试的作业。我没上过OOpre，也基本没有编程基础，写出来的东西从一团乱麻到最后能跑，能输出相对正确的数据，现在回想起来都好像在做梦。在手搓代码的过程中也肉体可感的体会到了自己在不断地接受新知识。只可惜时不等我，错过了很多更有意义的环节...下次继续努力了。

 

未来方向

只有完全吃透掌握的人才对难度有话语权。我只希望oopre能成为必修课。