OO第一单元博客

一、三次作业

1、第一次作业

自我评价总结：在第一次作业中仅仅涉及到简单的幂函数的求导，程序要处理的问题并没有十分复杂。经过了pre的预习，对使用正则表达式提取出需要的项也有一定的掌握，刚开始接触面向对象，在开始写程序的时候就比较不好地保持了写C语言代码的习惯，在第一次作业中 一Main到底，对读入数据的处理，也是在Main里面写了fHJ（符号化简）、sHJ（系数化简）两个private方法。因为没有更多使用面向对象的思维，使得程序的main类中过于冗余，向c语言一样，程序的可读性也没有那么强，最重要的是，为之后的作业 埋下了很大的隐患，可扩展性不强，面临重构的问题。

 

 

2、第二次作业

自我评价总结：在第二次作业中，在对数据的处理与存储时，我选择了按照四元组的方式来存储数据，把每一项统一化为a * x^b * sin(x)^c * cos(x)^d，用abcd四个数来代表每一项 ，每一项都保存在一个Shu的类中，在求导的时候，根据每一项，另外生成三个新的Shu对象作为求导的结果。同时在Shu的类中，因为是按照四元组保存数据，所以在输出的时候要还原成x、sin(x)、cos(x)的形式，增加了把四元组还原成字符串的output和toStirng方法。与第一次作业不同的是，这次没有采用一Main到底的形式，涉及到判断输入是否符合要求，我就增加了pDuan（判断）的方法。增加的方法包括对字符串++等符号化简空白符删除的预处理、对格式是否正确的判断、对项和因子的提取方法。这些方法让我感觉在第二次作业中，我的程序更加面向对象了，这些方法在第三次作业中也需要使用，增加了程序的可迭代行和扩展性。我觉得这次作业的最大问题就是我的程序不够OO，在对每个项的处理中，四元组仅仅是这次作业的特有方法，之后我又思考改进，觉得应该根据不同类型的函数：常函数、三角函数、幂函数分别建立不同的类，定义统一的接口来处理，这样的话对后来作业的嵌套函数、以及增加新的类型的函数的时候能有更强的扩展性。

 

 

 

3、第三次作业

自我评价总结：在第三次作业中 ，我发现我的程序逐渐体现出OO的特点，有了一定的层次性和可扩展性。首先在设计的时候，我选择了按照指导书的提示建立了Chang（常函数类）Mi（幂函数类）San（三角函数类）Biao（表达式因子）Xiang（项类）Biaodashi（表达式类）并且让他们继承同一个接口Yinzi，每一个类都要实现求导的方法。在读入一行数据中，继承了第二次作业的思想，先进行预处理和格式判断。基本思路就是最开始读入表达式，再根据表达式拆分成不同的项，再把项拆分成不同的因子，按照相应的求导法则进行求导，体现出一种层层递归的操作。因为向之间通过加减号连接，所以在提取项的时候，需要找到所有括号最外层的加减号，这里我就采用了“栈”的思想，记录左右括号的数目，遇到左括号+1，遇到右括号-1，对在外层的加减号进行标记，以便于对因子按照标记进行提取和分离，对因子的提取同理。对因子的判断中，我采取了工厂模式来判断是常函数因子，还是幂函数、三角函数、表达式因子，对于三角函数因子和表达式因子考虑到三角函数的嵌套，还要进行递归判断提取，对于表达式因子先拆掉括号，再按照表达式求导规则进行求导。第三次作业给我的收获就是在设计思维上更加清晰并且通过三次作业更加具有层次化，逐渐程序变得面向对象化，可迭代行得到了提高，更能站在对象的角度去思考问题、解决问题。但是第三次作业的遗憾是在我的程序中，没有进行对结果的化简，当时想不出来什么比较好的化简的方法，也觉得化简会使得程序的复杂度提高过多，容易产生很多的bug也就放弃了，之后听过同学的经验分享，学到了新的方法思路，以后还是要尽可能去挑战自己。

 

二、分析自己程序的bug

第一次作业中强测仅仅得到了38分的惨淡分数，究其根本，主要是粗心所致，在提交程序之前，我改了一下我格式化输出的内容，就错把print打成了println，导致所有的输出都是占了两行，本以为改格式化输出不会出现什么问题，也就没有过多举例测评，直接提交，结果强测爆炸，最后也都是同质bug，主要是粗心不严谨导致的问题，也让我在以后每次对程序进行改动之后，都选择重新进行数据的测试来检查程序。

第二次程序的bug也是粗心导致，在空白字符的定义中只有空格和水平制表符，但是我在程序处理时，直接按照正则表达式的\s来处理空白符，导致了强测遇到垂直制表符出现错误。

第三次程序的bug来自对符号整数的wrong format的判断缺少一种情况，在cos（- 1）中，符号整数作为因子，并且符号与数字之间存在空格这种情况没有在正则表达式中考虑到位。

综合三次作业的 bug，我觉得我写程序的时候对关键信息的提取和细节的记忆还是不够认真，考虑问题缺乏全面性，我觉得bug更多是通过大量的测试样例来测出来的，应该在写程序的时候，站在使用者的角度来想测试的数据，而不是程序设计者的角度，这样更容易去发现自己设计时没有考虑到的情况导致的错误。我发现我的程序的bug主要出现在对抽象层次进行判断和对抽象层次进行具体化的代码部分，为了减少bug和方便对小的模块进行测试，程序设计应该更加关注高内聚低耦合的原则。

 

三、发现别人bug的策略

在寻找他人bug的时候，我首先会使用我自己测试自己的程序的时候容易出错的测试样例进行测试，尽可能在测试别人程序的时候把测试的错误种类进行覆盖。同时我会主要测试一些边界的数据或者是特殊形式的数据，来试图找到漏洞。如果还是找不到错误的话，我会先去读他的程序的设计模块之间的关系，去看一下主要的思路，并且仔细阅读他在比较抽象的层次的具体处理方法，尽可能去寻找逻辑的漏洞或者是不是少考虑了情况，针对性测试。

 

四、应用对象创建模式来重构

就像是在上面的作业总结分析中说过的那样，在第一次作业的时候更多是面向过程去解决问题的思想，面向对象的特征比较差，在第二次作业中，就对格式判断，提取因子，对表达式进行化简预处理，把这些方法分别提取了出来，使得在第三次作业中可以进行扩展与改进，继续使用，增加了程序的迭代性，但是第二次作业中对各种因子的处理由于采用四元组的方法，不具备很好的面向对象的特征。在第三次作业中，对各种因子的处理时继承相同的接口，分别构建不同的类，并且递归的过程中，突出了使用工厂模式和有的类与类之间的依赖关系，不但提高了程序的清晰性、可迭代性，而且更加简洁明确。

 

五、总结和收获

在看了其他同学的代码之后，我发现他们的代码很好的体现出了高内聚低耦合的原则，每一个模块的功能清晰并且不冗余复杂，在类的设计划分方面十分细致，我应该继续不断向他们学习他们的设计思路和处理问题的方法角度。经过三次作业，我发现我debug的能力仍然不足，还需要不断提高改进。更应该去提高的是解决问题的时候，能够站在对象的角度，去更好更快的思考不同类之间的关系，学习怎么把问题去划分成清晰明确层次的能力。