oo第一单元总结

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所采用的策略

1. 看到长正则表达式，尝试在限制长度内考虑会不会爆栈，第三次做业因为添加嵌套结构，考虑套多层括号爆栈状况。

2. 正则表达式部分：

   · 在不应加空格的地方加空格

   · 加负号

   · 第三次做业能够尝试各类嵌套

1. 分析代码优化部分逻辑，由于中测中基本测试程序功能，因此优化部分更容易出错。

   · 循环没有及时跳出

   · 优化过程当中匹配的正则表达式，例如\d没有加'+'

四. Applying Creational Pattern

个人三次做业对面向对象的思想都体现得不明显，代码扩展性差，没法复用。并且彻底没有考虑过三角函数部分的优化，只是简单计算，致使性能低。

关于代码重构，我首先是想实现求导接口，将各类因子创建类，实现求导接口。而后再考虑将求导接口与项和表达式创建联系。我如今对于接口的运用还不是很明白，还须要再想一想。

五. 有关面向对象和面向过程的一点思考

由于我对面向对象的优点没有实际体会，运用也不熟练，因此在阅读第三次做业指导书后，我首先想到的是C语言数据结构中将表达式转化为后缀表达式，创建表达式二叉树，自底向上求导。

将sin,cos,^,*,都视为运算符，并给它们赋不一样的优先级

程序类图：

metrics复杂度分析：

我看到这道题的第二个想法就是递归，简单应用接口后的程序,

类图：

metrics复杂度分析:

个人第一种方法彻底没有用到面向对象的方法，其中的Node类只起到结构的做用，经过复杂度分析，能够看到圈复杂度和模块设计复杂度在输入格式检查和创建表达式树的几个方法中很是高，其缘由是因为后缀表达式会去掉括号，因此要在处理表达式以前进行sin(),cos()和（）^，几个结构的括号检查，而且在输出以前还要再进行一遍括号的添加和删减。

而在面向对象的设计中，能够经过创建类和应用正则表达式的方法，使输入格式检查变得清晰。

第一种方法在创建表达式树的过程当中，因为自底向上的求导拼接形式，对于括号的把握也比较困难，而且形成圈复杂度很是高，让程序的质量大大下降。

面向对象的编程能够下降模块间的耦合度，使程序结构化程度提升。