BUAA_OO_第一单元（表达式求导）总结
一、历次作业架构分析
1、 第一次作业
（1）总体架构
第一次作业因为没有三角函数，没有格式检查，也没有括号的嵌套，相对来说算是三次作业中比较简单的。在第一次作业中，我用到的是我在实验课上学到的方式，利用TreeMap存取每一个axb的项。
我分离项的方法是通过正则表达式中的零宽断言找到连接每一个项之间的加减号，并把它替换成空格。最后在通过spilit来分开。所以我分了两类，一类是主类，另一类就是每一项的term类。通过在主类中分得的项传入一个term，最后再通过重写equals和hashcode来实现相同指数合并的操作。
（2）度量分析
类图:
度量分析：
Prework是将得到的字符串，进行符号的合并，空格的缩进，以及相应字符的替换。Term中的get方法就是就是得到求导完后的指数和系数。Main中的out就是输出每一个项。并且每一个方法的复杂度不高，相对来说比较简单。
（3）优缺点
优点：将每一个项分离出来，并且给了每一个类。从而达到高内聚低耦合的效果，每一个项单独一个类，最后再合并同类项。
缺点：分的类可能不够细致，只有两个类，难以处理所有的情况，完全可以一边处理的时候，一边进行优化。并且在处理表达式的时候用正则，极容易出现意想不到的bug。
（4）bug分析
这一次出bug主要是因为优化的关系。因为我在term中处理时，只是合并了相同的指数的项，并没有去零。我在最后处理+0这种情况的时候，少考虑了全是0的情况，导致强测第一个点没有过。
（5）hack策略
我找别人的bug主要是通过自己初步调试代码的时候，出现错误的样例。并且会静态观察一下他们的代码。如果说结构很混乱的代码。我就会采取构造一些数值比较大的，一般常识上不会去够早的数据。例如这次我就发现一位同学的代码并没有处理零的操作。所以我就输入了0+0+0，就hack出来了。
2、 第二次作业
（1）总体架构
第二次作业因为有三角函数的加入以及括号的加入，导致难度陡增，因为自己在这一星期的时间安排上出了一点问题，导致没有很多时间去规划代码。只能够通过非常粗暴的方式解决这个求导问题。因为这次作业三角函数的形式全都是sin（x）和cos（x）这种，所以我通过正则将这些替换成了s，c。之后就是通过totalJudgeDerivation遍历这个字符串，如果找到连接每一个项的正负号，就将符号前面的字符串送入itemDerivation然后后面的就送入totalJudgeDerivation。再进行递归遍历。如果符号是负号，我会将后面的整个字符串加上一个括号，并且把里面连接项之间的符号取反。
（2）度量分析
这次作业因为自己比较恐惧，怕自己做不完，并且初步看递归下降没有看懂，更加焦虑，所以只能够通过这种方式先通过中测。本次作业就完全是用一个类完成的，求导的那些操作用的是方法去完成的。导致方法之间的耦合情况非常严重，并且方法的长度非常长。设计极其不合理。
类图：
度量分析：
这次作业可以说并没有真正体会到面向对象的思想，还是跟程序设计那门课一样，只是分析没一个过程，在我看来，完成的比较糟糕。每个方法的复杂度报表，并且长度还长，代码十分丑陋。
（3）优缺点
优点：可能是对于第一次学面向对象，上手简单，思路简单，说白了可能就是将c语言通过java翻译了一下。
缺点：缺乏面向对象的思想，只通过一个类去写java，完全就是没有考虑面向对象的思想。并且一个类中的方法冗长，方法与方法之间的调用极其频繁，性能极低。并且还完全没有考虑合并等优化因素导致性能分极低。
（4）bug分析
由于自己设计的原因，导致输出的结果十分长，为了减小长度，我进行了优化，通过将指数为0的项换为1,。但是由于粗心，忘了指数可以有前导零，导致我会将sin（x）**+012这种换成112.导致错误。就是因为这个错误导致我强测挂了11个点，想想是非常的后悔。出现了bug的方法和未出现bug的方法的差异其实并不大，这可以说就是细节上的考虑不到位。
（5）hack策略
因为在阅读别人的代码中，发现他们处理项与项之间连接的时候，并没有很仔细的考虑连接符为负号的情况。所以我就构造了几个负号的情况。
3、 第三次作业
（1）总体架构
因为这次作业加了格式检查以及三角函数中能够嵌套。所以我加了一个单独的类通过递归下降进行格式检查，格式检查通过后才可以进行求导。在求导之前，先通过prework将字符串与处理一下，缩进空格，合并符号。这次我创建了factor，item，totoalJudge三个类，来处理字符串，先将字符串传进totalJudge的类。与第二次作业相同的方法，找到连接项的符号，再通过递归进行处理，唯一的区别就是对于factor的区别上，因为factor的三角因子中可以再套一层factor，所以还要进行一次递归。所有的求导都是在factor中求导。所以求导的终止条件，也就是factor中求导完成后。
格式检查的check类按照如下文法，进行判断如果符合就往下进入item中，再进到factor中，当发现不符合情况是就直接error出去。程序结束。这其中用到的就是递归下降的思想。其实就是翻译这些文法。实现起来就是细节上要多加考虑。
（2）度量分析
这次作业相对于上一次作业，我添加了多个类来解决上一次作业中方法过多的情况。
类图：
这次我将对总体求导和对项求导以及对因子求导分别开了三个类。然后格式检查开了一个类。应该说，这几个类之间分工明确。结构清晰。应该达到了高内聚低耦合的效果。
度量分析：
还是同样的问题因为我将上一次作业的求导的方法进行了沿用，只是开了不同的类，但是方法还是那些方法，导致了复杂度还是比较高。还是完成的不太合理，不太美观整洁。
（3）优缺点
优点：在于结构非常的清晰，一个类管理格式检查，另外几个类完成表达式的求导的工作，思路上非常清晰，低耦合。
缺点：细节考虑的非常多，非常容易出现意想不到的bug，类与类之间的调用，经常因为细节的原因导致bug的产生。
（4）bug分析
因为这次的格式检查，我被hack了几个点，我在对于括号的判断上出现了错误，我只是判断了左括号出现后，右边括号有没有，有就是对的，没有就是错的。导致我无法判断多层括号嵌套之后，右边括号缺失的情况。还有一个就是表达式因子不能有指数这一点没有考虑到。因为sin（x）这种括号后可以带指数。并且我判断的时候将表达式因子和三角函数归为一类。导致这个bug难以修复，除非改架构。最后我发现我的代码好像只有判断括号这类的发生了错误。所以我在主函数类中写了一个专门判断括号的方法。如果左右括号不对等，直接error，如果指数前面是括号，且不是三角函数的括号，直接error。
我分析出现了bug的方法和未出现bug的方法在代码行和圈复杂度的差异其实并不明显，都是通过循环遍历整个字符串进行相关的操作。
（5）hack策略
我听过静态观察代码发现，有同学在处理括号嵌套括号的时候，里面的正负号没有很仔细的考虑。所以我就构造了一个（-（x**-2））的例子，就hack到了。所以总的来说，我hack别人会首先看一下他是如何去处理求导这一些细节上的操作的。如果我一下子没有看到，我就会在这一个点上去构造数据。
二、重构经历总结
因为自己在时间安排上出现了一点拖沓的情况。导致我每一次的作业都非常赶。在第一次作业的时候就没有设计一个可以贯穿整个单元的架构。这导致我三次作业重构了三次。
难道说自己想不到这些架构吗？其实也不是，只是自己没有充足的时间，或是自己的心态随着ddl的临近发生了变化，变得急躁。对于重构非常的恐惧。但是不重构又难以完成任务。
这时候我的方法就是沉住气，一步一步考虑应该用什么架构。多与人讨论交流。第一次作业因为没有嵌套，三角。只有x，我就用一个TreeMap就搞定了。但是下一次的作业有这些了，我就只好重构了，通过将表达式分成total，item，factor进行相应的求导。最后一次作业就是加了一个格式检查以及因子之间的嵌套。这次重构的程度比较小。
三、心得体会
本单元完成之后，给我最大的感受，就是抗压能力。我从第一次作业开始就怀疑自己能不能写出来，从而导致我每一次的信心都不是很足。从而导致我自己每一次过了中测之后，就不敢再去管强测。但是每次强测被hack了的时候，看了一下，发现完全是可以改的，完全是可以通过课下测试改掉的。这个时候的自己又非常懊恼。
还有一个就是时间的安排上要抓紧一下，周三发布题目，周天交。就只有四天的时间，周四还是满课。所以时间上不能拖沓。早构思，构思充分了，以第一单元的经验来看，完成的分数也还是不错的。
最后，通过本单元的学习，我认识到自己对于面向对象的思想上的理解还存在不晓得盲区。以及对于类与类之间的结合，使用，还比较生疏，才会出现第二次作业，只用一个类的情况。所以，在准备接下来的单元时，我要调整好自己的心态，以及更好地时间管理，还有学习更多的面向对象的知识。来较好地完成第二单元的作业。
