OO第一单元作业小结
在本次博客的写作中，我运用IntelliJ旗舰版的Diagrams功能绘制类图，用MetricsReloaded插件进行代码复杂度分析。
(1)基于度量来分析自己的程序结构
第一次作业
第一次作业的流程图如下：
第一次作业的结构比较混乱，因为较少接触面向对象语言的缘故，所以程序写的一点也不面向对象，反而非常的面向过程，只设计了两个类Poly和Term，连IO这个类都没有设计，而是选择把IO操作放在Poly类的main方法中来实现，而且每个类的方法数也较少，每个方法的代码数很长，难于维护，这样的操作背离了面向对象的初衷。
第二次作业
。。。
在第一次作业中学习了别人的代码之后，第二次作业将IO单独列为一个类，此外设立了Poly、Term、Factor三个类，并且将方法细化，方法数增多了，每个方法的行数减少了，易于理解。
第三次作业
在第二次作业的基础上，类的数目进一步增多，对字符串的处理也单独列为一个类，程序越来越面向对象了。同时，由于没有学会递归下降法，而是自己使用了一个类似于递归下降法的方法用正则表达式写出了程序，复杂度比较高。
(2)分析自己程序的bug
第一次作业
第一个bug产生于对指导书没有进行咬文嚼字的认真分析，误以为“在本次作业中，空白符仅包括空格和\t”的意思是输入的时候输入的空白符只包含空格和\t，因此在正则表达式中只采用了\s作为匹配空白符，所以导致了\f这样的隐藏空白符会产生程序bug，本应输出WRONG FORAMT!却匹配正确。
第二个bug产生于对空串的理解不当，误以为空串就是“”，所以用ctrl+z会炸我程序。
第三个bug产生于正则表达式的匹配方式，整体匹配是一种性能极差的匹配方式，字符串稍微长一点就会爆栈。其实最有效的方法应采用逐项匹配，利用Pattern和Matcher类的find方法对字符串分步解析，这样对再多的项组成的字符串也不会爆栈。
第二次作业
第二次作业的bug产生于各个类之间的信息交流，有些类的字符串是带空白符的，有些没带，把Poly类的字符串传递给Term类时因为空格的问题产生不兼容。
第三次作业
第三次作业的bug产生于对符号的处理，由于在Factor类中的求导结果会产生-号，在有多个-号时会使程序产生错误。
(3)分析自己发现别人程序bug所采用的策略
在发现别人的bug时，我首先观察了别人引入了什么包。例如引入了ArrayList我就知道他是利用了ArrayList这样的数据结构来存取数据，引入了Hashmap我就知道他是利用了Hashmap这样的数据结构来存取数据。有的程序没有引入BigInteger,我就输入一个超出了long,int等基本数据类型表示范围的字符串，成功刀到人。对别人的程序采取覆盖性测试，如果实在做不到就尽量多对边界数据进行测试，因为一般的数据肯定刀不到人，所以尽量输入特殊的数据，例如+++1，+++ 1这些非常特殊的数据。
(4)Applying Creational Pattern
通过第一单元的学习，我对面向对象有了较为清楚的认识，知道面向过程与面向对象的区别，思维也从面向过程逐渐过渡到面向对象。编写工程代码不能再像以前一样想到哪写到哪，在编写代码时前要构思好程序的设计框架，可以先把各个类的名称，方法名写出来，写完之后再写具体实现。除此之外完备的测试样例也是极为重要的。
通过互测，不仅可以增强自己发现bug的能力，还可以从别人的代码中学到很多东西。例如我从别人的第一次作业中学到了如何面向对象，从别人的第二次作业中学到了继承与接口，从别人的第三次作业中学到了递归下降法的词法分析。这样对我的编程能力是极大的提升。