BUAA_OO_第一单元随笔
本文将按照作业五个要求分为五个模块来分析。
基于度量来分析自己的程序结构
首先当然先从 UML 之中看一下大致的结构。
可以看出，我的设计分为三元素：Poly、Item、Factor，这是围绕多项式的结构来设计的，Poly 也就是多项式，Item也就是项，Factor也就是因子，MyConst 也就是我的常数类，里面放了很多经常用到的常量，比如匹配项、因子的正则表达式等等。而 Factor 又分为了 PowerFactor、SinFactor、CosFactor这三种因子，其实这也就是作业要求上的五种因子之三，另外两种是带符号常数和表达式因子，比较特殊就没有设置这两种类。
这是对于我的十一个类的分析，可以很明显看出来，OCavg的复杂度属 Factory 最高，确实，它做了很多字符串处理的操作，以及正则表达式的匹配，而且很多都是遍历，但是至于 Item 和 Poly 这两个类，还是因为要完成简化的操作就又大量的循环遍历存在，对于本次作业的60字符可以承受，大都控制在 0.2s 左右，但是如果增加的话，可能会有TLE这种情况，可以对其进行优化。
分析自己程序的bug
前两次作业都没有bug，第三次作业中有两个。
- 互测中有一个，原因为 Factor.toString() 要对括号里的 para 进行判断是否可以当作因子，因为这样可以少输出一个括号，但是我用了字符串自带的 matches() 方法，我以为它是整体匹配的，没想到只是从头匹配。
- 强测也有bug，是完全将sin()括号里当作 Poly 处理了，忘了表达式因子必须带()，所以sin(1-x)在我这里是合法的。
分析：大意了，还是测试的不够完全，没有测试这种格式错误的，自己搭的评测机又测不出来带不带括号，还是测试不够充分（测自己的热情远不如测别人），写代码时粗心大意了。
分析自己发现别人程序bug所采用的策略
我用了两种
- py用xeger生成数据，用sympy测试正确性，结合shell脚本自动化测试，但只可以评测出正确性，不能判断其输出格式的正确
- 写了个shell脚本，自己手动输入数据，会将所有人的结果输出，通过”肉眼观察法“，判断正确性，这样我们可以针对性构造一些样例，对其覆盖测试。具体实现如下
- 至于是否结合被测程序的代码设计结构，一般我是不看别人代码的，太长了。
#!/bin/bash
if [ $# -eq 0 ]
then
echo please input your data to hack them
else
ls -d */ > students.txt
cat students.txt |
while read line
do
cd ./$line
head=$line的输出是:
ans=$(echo $1 | java MainClass)
echo $head $ans
cd ..
done
fi
应用对象创建模式
第一次作业
第一次作业用了MainClass、Poly、PolyFactory，这三种类，PolyFactory也就是工厂模式，也没什么设计，就这两个类，应该算是简单工厂模式。也就是将字符串处理一下，主要用了正则匹配逐步转化的这个操作。
第二次作业
然后其实第二次作业的时候基本上我的主要架构设计已经形成了，也就是这么多类，只不过由于三角函数括号里的东西很单一，我用了一个普通数组来存储不同因子，这是为了提高效率，以及为了化解时可以很快的进行数据处理。
第三次作业
uml图同于第二次作业, 最大的区别在于Factory 中对字符串的处理复杂了很多, 由本来的一条龙改变为递归解决。以及在Factor 中加入了 para 这一元素用来保存三角函数括号中的 Poly。以及进行了一些合并同类项的优化。
对比和心得体会
代码扩展性做得好可以节约很多时间，主要还是在设计上花费时间较多，以后一定提高对于测自己的热情，别总想测别人。