OO-第一单元总结
PS：
此次作业总结中，我将依照两个版本的代码进行分析，其中版本A为提交并参与测试的代码版本，版本B为重写，但未能参与测试的版本。
分析(A)
前言：这次作业我只用了五个类，写的比较面向过程，基本思路是先用正则来过滤掉一些WF,再格式化字符串来方便读入。表达式分析上是先将字符串转换为后缀表达式，再依次弹出，先后封装为因子、项、表达式，然后从上往下调用各类中的运算方法，最终合并为一个表达式对象。表达式的一些化简是在计算后缀表达式的同时进行。因为展开了括号，所以性能分上比较随缘，正确性靠着缝缝补补勉强通过。
工具 MetricsReload [1]
类关系图
复杂度分析
Expression-类
维护一个HashMap<String, Item>对象
其中合法性检测和格式化的方法中用了大量的if进行正则匹配，基本复杂度和圈复杂度较高。
运算、求导和符串化方法主要靠遍历调用哈希表中的项们来实现的。
复杂度分析
Item-类
Item类作为表达式类和因子类的中间类，构造比较简单，维护一个HashMap<String, Factor>对象，实现了一些项之间基本运算和化简的方法。
复杂度分析
Factor-类
根据type属性的不同，维护两个BigInteger和一个Expression对象，由于除type外的属性都设置了set方法，使得其对外是可写的，也因此产生过Bug，在B版本中仿照BigInteger类进行了修改。
Factor类中运算方法和化简得实现都比较简单，比较重要的是维护求导方法中的switch。
复杂度分析
两个Processor类
当我回想起之前写Swing的时候，一时兴起写了这两个类，却只得其形，较为失败。
这两个processor颇为面向过程，FactorProcessor类维护两个HashMap对象，分别用来存放Factor类型、操作符类型，一个String对象用来存放格式化后的输入，和一个boolean对象。
FactorProcessor的作用便是从输入中读取下一个因子或操作符，并判断其合法性，语法合法性则交由ExpressionProcessor实现。
复杂度分析
Bug分析
第二次作业中仅遇到了格式化过程中的问题，像(+(+(+(，除去其中所有的+号需要对输入进行递归处理。虽然BUG不多，但也因此暴露了这种方法相对于递归下降的缺陷。
第三次作业遇到了较多的BUG，但大多是因复杂度较高而难以维护造成的，通过单步调试勉强填上，便不一一赘述。
版本迭代
第一次作业出于某些原因没有完成，所以我只经历了一次重写的经历。第三次作业中，相比于第二次作业，第三次作业加入了极为面向过程的合法性检测方法，在fd维护的factor类型中加入了嵌套表达式因子的类型，并在factor求导方法维护的switch中加入相应的分支。因为factor的getType方法能够区分包括嵌套三角函数的各类因子，所以对各运算方法的修改不是很多。
分析(B)
前言： 版本B的代码是我在第三次作业时重写的代码，但因某些原因没有提交成功。代码基于递归下降而写，可维护性大幅提高。
类关系图
复杂度分析
考量
虚拟类Unit，作为所有因子类、符号类的公共父类，维护一个UnitType枚举类只读对象。
虚拟类Factor，实现Cloneable和Derivable接口
各因子类继承于虚拟类Factor，通过工厂类UnitFactory进行构造。
Operation类继承于虚拟类Unit，并充当各符号常量池的作用。
MyItem类实现Item、Cloneable、Derivable、RecursiveParse接口，维护Factor链表类对象，和UnitSign类对象
MyExpression类实现Expression、Cloneable、Derivable、RecursiveParse接口，维护一个Item链表类对象
RecursiveParse接口，主要实现用于递归下降的重要方法parse，通过泛型提高可拓展性。
虚拟类MyException作为各异常类的公共父类，与Exception相区分，用于抛出合法性检测异常和提高可维护性。
