OO第一次博客做业（第一单元总结）

Q：菜是绿的，鸡是黄的，那菜鸡是什么颜色的？

A：红的，强测全WA了，能不红么。

菜不菜的问题先不说了，认真研究一下此次的题目，以及WA的缘由吧。

程序结构简析

三次实验的核心结构都是差很少

第一次的没什么好分析的，每一个Item能够用固定的方式表示：num * x ^ n（暂且不考虑格式），而后拼成表达式就好了。

 

第二次，以Item为最小单位显然是不现实了，每一个Item的项数和项的种类都不肯定，那么就用抽象类Factor做为基本单位，常数因子、幂函数因子、sin函数因子和cos函数因子做为该类的具体实现。

每一个Item用Arraylist<Factor>实现（不会用Hashmap），每一个表达式Expression又用Arraylist<Item>实现。

继承关系很容易看出，由Expression为父类，子类Item，而后是抽象类Factor和实现Factor的四个子类。

全部的类都实现一个求导接口，从最底层的四个Factor实现类写起，Item的求导采用乘法求导公式循环求导，Expression求导采用加法求导公式逐个求导。

简化的方法，就是将每一个项变为常数因子*幂因子*sin因子*cos因子的标准形式在进行相似第一次做业的简化。

虽然第二次的重构很是痛苦，可是好处是第三次求导能够特别快速地进行：只须添加一个继承Factor类的表达式因子，修改一下sin函数因子和cos函数因子，就能够实现第三次做业的基本功能了。

因为第三次做业简化要求太复杂就不作简化了。

 

这里只放出最后一次做业的度量结果，从结果上看，还有很大的优化空间，主要是表达式处理上有很粗糙的地方，表达式读入的方式仍旧过于面向过程，写了冗长的函数体。

分析本身程序的BUG

BUG的缘由真没什么好分析的，前两次都是在简化的时候发生了对输出的错误处理。可是，两次采用的简化方法并不相同，因此致使BUG的缘由也不彻底相同。

第一次的简化策略是，逐项输出，以项为最小单位进行简化。在简化中，要考虑常数、幂指数为0、一、-1等的状况。输出表达式时，用+或-进行链接。错误的缘由是在常数为0时多输出了一个+号，项却已经被简化没了。

第二次的简化策略还是以项为最小单位进行简化，但因为此时的最小单位为因子，因此简化起来和第一次相差很大。此次是根据未简化时产生的字符串按正则表达式简化，但因为状况考虑疏忽，致使简化了不应简化的状况，强测出现大量BUG。这就是一个教训：在第一次做业的BUG修复以后，在容易致使BUG的薄弱环节上就不应另起炉灶了。

除此以外第二次还有一个地方在拷贝代码时少改了一个变量名，致使求导求错。

第三次的话，就是注意一下评测机系统的System.exit返回值必须为0，否则就会RUNTIME_ERROR就是了。其实在中测的时候就已经发现了这个问题，可是还有一个System.exit(-1)没有改掉，说白了仍是本身不细心。

分析本身发现别人程序bug所采用的策略

头两次由于Bug都分在了C组，用黑盒盲测的方法就能发现许多BUG（并且都是一些各类各样无厘头的WRONG FORMAT类问题，技术含量真心低），第三次也无意投入太多时间用来找BUG，因此没什么可谈的。

值得一提的是，有时采用代码评审的方式，可以从代码中直接找出BUG的存在，这个方法在之后处理多线程程序时会起到很重要的做用。

Applying Creational Pattern

若是没错的话应该是用了一个叫什么工厂模式的东西，虽然并非有意识地在用，写的时候也并不知道这个东西。不过设计模式这个东西真的挺有用的，建议课上多讲一些。