oo第一单元总结
一.基于度量来分析自己的程序结构
1.第一次作业
思路：先判断输入格式，通过正负号切分，求导拼接。
statistic分析：
metrics复杂度分析：
类图：
第一次作业代码共208行，从互测组对比来看，代码行数较少。基本复杂度为1，说明代码是结构化的，但圈复杂度和模块设计复杂度都非常高，说明程序分支多，质量低，模块间耦合度高，模块难以隔离维护。我认为造成这种情况的原因是在同一个函数中实现太多功能，并且只用了一个类导致的。
2.第二次作业
思路：将每一项分为常数，x，sin(x)，cos(x)四个部分，分别记录四个部分的指数，完成求导。
statistic分析：
metrics复杂度分析：
类图：
第二次作业代码共379行，初步尝试应用多个类，代码结构化程度降低，平均圈复杂度和模块设计复杂度相比第一次作业都降低一些，但还是很高，主要原因是类的数量过少以及在我尝试进行少许化简的过程中同一函数试图完成的功能过多。
3.第三次作业
思路：将表达式拆分成项，项拆分成因子，递归求导。
statistic分析：
metrics复杂度分析：
类图：
第三次作业代码共653行，结构化程度低，平均圈复杂度和模块设计复杂度相比第二次作业又降低一些，但仍然很复杂，没有用到继承和接口，主要就是将表达式拆分成项，项拆分成因子的递归思想。
二. 分析自己程序的bug
1.第一次作业
在互测中被找到一个bug，有关正则表达式，输入
0*x^+0
我的程序输出WRONG FORMAT!
原因是判断表达式格式时分为其它项和第一项两部分来匹配，先匹配除第一项外的其他项，此时将+0当作一项，表达式格式错误。
改正：第一项前若无符号，在表达式前添加'+'，然后逐项匹配。
2.第二次作业
在互测中被找到2个bug，都是有关正则表达式，第一个是判断四个符号相连错误时中间忘记加空格，即程序可接受++ ++1这样的形式，第二个是由于用了split('*')没有判断最后一个字符是不是'*'，所以程序可接受2*这样的表达式。
3.第三次作业
在强测中被找到一个bug，在互测中被找到的也是同一个bug，原因是没有考虑到（）前有'-'的情况，即输入
-（x)
我的程序输出WRONG FORMAT!
改正：合并修复，不在意性能，将所有"-()"改为"-1*()"。
综上：其实三次作业的错误都集中在正则表达式部分，与程序结构关系不是很大。
三. 分析自己发现别人程序bug所采用的策略
-
看到长正则表达式，尝试在限制长度内考虑会不会爆栈，第三次作业由于添加嵌套结构，考虑套多层括号爆栈情况。
-
正则表达式部分：
· 在不该加空格的地方加空格
· 加负号
· 第三次作业可以尝试各种嵌套
-
分析代码优化部分逻辑，因为中测中基本测试程序功能，所以优化部分更容易出错。
· 循环没有及时跳出
· 优化过程中匹配的正则表达式，例如\d没有加'+'
四. Applying Creational Pattern
我的三次作业对面向对象的思想都体现得不明显，代码扩展性差，无法复用。而且完全没有考虑过三角函数部分的优化，只是简单计算，导致性能低。
关于代码重构，我首先是想实现求导接口，将各种因子建立类，实现求导接口。然后再考虑将求导接口与项和表达式建立联系。我现在对于接口的运用还不是很明白，还需要再想想。
五. 有关面向对象和面向过程的一点思考
因为我对面向对象的优势没有实际体会，运用也不熟练，所以在阅读第三次作业指导书后，我首先想到的是C语言数据结构中将表达式转化为后缀表达式，建立表达式二叉树，自底向上求导。
将sin,cos,^,*,都视为运算符，并给它们赋不同的优先级
程序类图：
metrics复杂度分析：
我看到这道题的第二个想法就是递归，简单应用接口后的程序,
类图：
metrics复杂度分析:
我的第一种方法完全没有用到面向对象的方法，其中的Node类只起到结构的作用，通过复杂度分析，可以看到圈复杂度和模块设计复杂度在输入格式检查和建立表达式树的几个方法中非常高，其原因是由于后缀表达式会去掉括号，所以要在处理表达式之前进行sin(),cos()和（）^，几个结构的括号检查，并且在输出之前还要再进行一遍括号的添加和删减。
而在面向对象的设计中，可以通过建立类和应用正则表达式的方法，使输入格式检查变得清晰。
第一种方法在建立表达式树的过程中，由于自底向上的求导拼接形式，对于括号的把握也比较困难，并且造成圈复杂度非常高，让程序的质量大大降低。
