OOP第一章总结

经过了三周的OO，尽管过程不太轻松，但是有所得还是值得欣慰的事！

---

 （1）程序结构

第一次作业：

　　UML类图如下，第一次作业在结构上并没有太多面向对象的思想，只是简单的分类，一个运行类，两个对象类，预处理都是直接在运行类进行的，所以有点乱（于是第二次果断重写了-_-！）

 　　复杂度如下，因为带有一定面向过程的原因，写的也没有特别复杂，所以看数据还好，但是在结构上不得不承认，确实是很糟糕，完全无法扩展，以至第二次作业得重新布局，不过也确实在重新构思的过程中理解了第一次的问题所在，明白了面向对象从人的思维角度出发的特点，尽管如此，第二次作业还是写的有点乱。

第二次作业：

 　　第二次作业主要加入了三角函数，理论上基于第一次作业进行扩展并不会很难，而且也使用了继承和多态，并且思考了如何为第三次作业的扩展进行服务。

 　　通过类图可以看出，父类为Factor(因子)，子类有四个，常数，幂函数，sin(x)以及cos(x)，然后Poly类为多项式，Term类为项；Poly包含Term，Term包含Factor。RegEx类用来进行正则处理，Optimize类用来优化，Main为运行类。

（由于方法太多，这里放的是类的复杂度）

 　　因为基本的处理都是在mian里面，所以main的复杂度很高，但是相比第一次，程序的逻辑更清晰，当然代码量也有了很大的增加（这里有个小疑问，是不是结构的层次化和清晰就意味着大量的代码呢？在读hdl代码时发现他的结构在我看来无比复杂，而且代码很多，但是考虑的确实很全面，）。

　　至于第二次作业的优化，在合并同类项的基础上只考虑了sin^2+cos^2=1这种情况，由于不会使用随机优化这种东西，导致优化的很差。

第三次作业：

 　　第三次作业加入了嵌套和表达式因子，个人做法是递归判断并且处理，但是没有使用助教所讲的那种递归下降法，而是直接在类的创建和求导过程中递归求解，这种做法的好处是只需要递归一次就可以得到不优化的结果（我的架构在优化时必须再次递归优化，而且bug很多，但是只要不优化，就没有问题^-^）。以下是类图：

 结构还算清晰，基本思路也比较符合助教的思路，就是递归考虑：

1）首先处理多项式，利用运算符“+”和“-”来进行分割，此处需要判断运算符

2）对第一步分割出来的Term项进行处理，利用“*”进行分割，产生因子（Factor）

3）对不同种类的因子进行不统的处理（这里共有五个子类：常熟，幂函数，sin，cos，和表达式因子）

4）每个因子类重写求导接口，最后递归输出（为了保证正确，需要大量的括号，也给优化带来很大的麻烦）

以下是复杂度：

　　可以看到，那个Handle类神奇的突破了60（好吧，我就是把所有处理方法写到了一个地方）

　　所以这里还有一个疑问，处理类该这么进行合理的分配呢？（输入处理，输出处理，求导处理等等？？？）

　　对于第三次作业，优点可能就是不优化我就不会爆炸（其实是写了优化的，但是有些问题，不敢用了┭┮﹏┭┮）

　　但是在处理过程发现还是有些问题，就像是接口这个东西，只是强行安在了求导上面，没有学会如何正确优雅的使用，再有就是预处理的问题，由于正则表达式在一开始不能使用，那么怎么全面的排除所有的WF让人头很大（骚的就是没有检查WF，不然我感觉自己的bug会出现很多），再者在优化时，思路是递归处理括号并且合并同类项，但是我也在同时担心，这样做会不会超时，不优化的情况下最后一个中测点跑了28M，尝试优化后40M+，就不太敢了，希望可以看到第三次作业的优化巨佬的代码学习一下！！

（2）自己的bug

　　可能我是直接写了一个bug出来！代码百千行，bug处处藏！格式不规范，强测两行泪！

　　第一次作业的bug主要是忘记了无脑空格，出现的原因是我在开始阶段判断了空串不合法，但是在空格替换后也可能出现空串，所以对于“         ”这种输入就会出错。

　　第二次作业的bug是正则表达式不小心删掉了一个“+”（这谁想的到啊），关键还是强测没有测这个。。。。。。

还有一个bug是在优化1*-1*这种情况时，忽略了^-1这个东西，导致出现了sin(x)-cos(x)^2.....这种东西，是自己的优化背锅

　　第三次作业的bug是不优化，对，没有优化就没有bug，所以这一次没敢加优化，也就没有显性的错误，至于WF，可能会有漏洞，但是自动化测试目前没有测出来。

（3）how to find a bug（对，就是a bug，那个狼人，说的就是你，找那么多干嘛？）

我的主要方法当然是——随缘大法，开玩笑的，不要当真，debug还是个苦力活

　　仔细阅读代码固然是不可或缺的，但是上来先进行一次全面攻击，会使的找bug更有针对性，也更多容易发现bug，这里有个小想法，不知可不可行，就是开放其他人被hack数，这样就更利于去查找了，同时隐藏自己的被hack数，于是就更加不敢不去找bug了，当然风险就是南湖人数增加！但是从OO学习的角度来看，我知道他一定有bug时，就会无所不用其极的找问题，而且对于所有人hack的同质bug，被hack者一波就可以修复，本身并不会损失什么，当然最慌的就是我自己看不到自己的情况，这谁敢不好好查找（前提是大家心态都要好一点，不要太在意分数，但是发现问题对于学习应该更加有利才对，而且同质bug的策略也不会损失很多）。

以上是胡言乱语，不可轻易相信！

 （4）重构?

　　讲真，一个月的学习过去了，对于OOP，我可能还是处于弟弟阶段。对于面向对象这个东西，掌握的确实不好，一方面可能是时间比较少，在构思后容易害怕写不完就匆忙工作，导致效果不如人意；反思自己的做法，我认为，必要的系统看书学习是不可或缺的，之前以为看了网页上的java教程我就稳了，是稳了（挂科稳了，啥都不会），再者大量的练习真的是不可或缺的，诚然OO作业工作量大（但周五上机那个是真做不完），三次作业我总共写了2000行代码左右吧，其中不乏问题和bug。

　　对于重构，在听完助教的parse递归处理方法后，感觉这个确实很诱人啊，准备去尝试一下，希望自己能重写成功吧（重构是不可能的了）。