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、-1等的情况。输出表达式时，用+或-进行连接。错误的原因是在常数为0时多输出了一个+号，项却已经被简化没了。
第二次的简化策略仍是以项为最小单位进行简化，但由于此时的最小单位为因子，所以简化起来和第一次相差很大。这次是根据未简化时产生的字符串按正则表达式简化，但由于情况考虑疏忽，导致简化了不该简化的情况，强测出现大量BUG。这就是一个教训：在第一次作业的BUG修复之后，在容易导致BUG的薄弱环节上就不该另起炉灶了。
除此之外第二次还有一个地方在拷贝代码时少改了一个变量名，导致求导求错。
第三次的话，就是注意一下评测机系统的System.exit返回值必须为0，不然就会RUNTIME_ERROR就是了。其实在中测的时候就已经发现了这个问题，但是还有一个System.exit(-1)没有改掉，说白了还是自己不细心。
分析自己发现别人程序bug所采用的策略
头两次因为Bug都分在了C组，用黑盒盲测的方法就能发现许多BUG（而且都是一些各种各样无厘头的WRONG FORMAT类问题，技术含量真心低），第三次也无心投入太多时间用来找BUG，所以没什么可谈的。
值得一提的是，有时采用代码评审的方式，能够从代码中直接找出BUG的存在，这个方法在以后处理多线程程序时会起到很重要的作用。
Applying Creational Pattern
如果没错的话应该是用了一个叫什么工厂模式的东西，虽然并不是有意识地在用，写的时候也并不知道这个东西。不过设计模式这个东西真的挺有用的，建议课上多讲一些。