OO第一次总结做业

第一次OO博客做业

前言

   面向对象课程已经通过了4周的时间。前三次做业所有是关于多项式求导的相关内容，内容由易到难，同时我也开始逐渐深刻感觉学习面向对象的各项特征，逐渐将本身的编程风格从C向真正的面向对象语言转换。同时我还接触了DEBUG和互测屋这样崭新的学习方式，在阅读别人代码的过程当中不断加强本身的编程能力和学习能力。

本篇博客将结合3次做业内容，分别从题目的理解思路，代码风格和度量，BUG的产生以及修复和Applying Creational Pattern共4个方面分析我这四周以来的工做。

1、第一次多项式求导做业

第一次做业相对以后的2次简单许多，可是因为是第一次运用JAVA编写这样有必定规模的程序，对我仍是有必定挑战的。

我将第一次做业大体分为3个阶段，包括多项式的格式检查，多项式的求导以及最后的化简输出。在第一步的格式检查中先检查空格部分，再将空格删除，用一长条正则匹配全部字符。在求导部分对每一项进行匹配，共有5种格式可能，分别对这5种状况进行求导，同时将结果存入HASHMAP中，最终在最后的化简输出函数中对指数相同部分，以及0，1进行化简，最终输出。

         如下为第一次做业的类图：

   相信这应该是我所写过的最面向过程的JAVA程序，整个程序自始至终只有一个类，而且整个程序的结构相似于C程序那样流水线的顺序结构，将全部函数以及数据都封装在同一个类里。这直接致使了在第二次做业的没法扩展，只能推倒重来。

第一次做业BUG分析

在第一次做业个人程序在测试中总共检出过2个BUG，分别为正则爆栈以及逻辑判断式中的计算顺序问题。

         首先是正则爆栈问题。在第一次做业中因为第一次使用正则表达式，没有采起分段匹配的方法，而是对整段统一一块儿匹配，以下图所示。

 

因为在第一次写正则表达式时使用贪婪匹配，直接致使程序爆栈。在DEBUG中将其改成独占模式进行匹配，得以解决问题，但在风格上无疑是很很差的。所以在后2次做业中进行了逐项匹配。

第二个BUG属于比较低级的错误

 

  问题出如今mlj2中，在BUG修复前没有括号，而判断目的是先进行或运算再进行与运算，与默认运算顺序不一样，致使格式判断出现错误。

总结

整体第一次做业难度不高，但因为是第一次编写有必定规模的JAVA程序，在程序风格，重构考虑以及细节等不少地方都没有作到位，也算是给本身长了一次教训。

 

 

2、第二次多项式求导做业

第二次做业相对于第一次做业增长了sin(x)和cos(x)求导，相对于第一次做业须要增长对于sin(x)和cos(x)的正则识别，同时在求导规则和化简上增长了必定的难度。整体上格式判断与第一次求导做业相同，但了可能的三个运算符与数字的组合，须要在第一次求导格式判断的基础上增长一个新的判断函数。在最终结果方面，将每一项变为a*x^b*sin(x)^c*cos(x)^d的形式，并在最后根据状况进行化简。

如下为第二次做业的类图：

 

 

  在第二次做业中我首先将整个多项式做为一个Poly类，对其进行空格检查。在删除空格后经过加减号进行划分，将整个多项式分解为各个独立的项，在对每项进行格式检查后进行求导，将求导造成的 abcd4元组变换成字符串存入Arraylist中。最后将系数项相同的部分以及1和0进行化简，最后输出结果。复用了第一次做业的空格判断函数，但在函数求导上与第一有较大差异。第一次做业使用HASHMAP进行储存，而这一次使用ARRAYLIST，因而只能大规模重写。

  整体代码风格上较第一次有比较大的改善。我总共创建了2个类：多项式类和项类，在多项式类中进行空格和符号的格式检查，以及最后的化简输出工做。在项类中进行每一项的格式检查以及求导工做。但在细节等不少方面都有能够增长的地方，例如使用接口进行规范。同时我也没有让项类继承多项式类的部分特性，而是重复编写了许多相同功能的函数。以及在格式检查传递错误信息中我使用了变量传递，虽然在原理上可行，可是是不被推崇的编程方法，所以在第三次做业中经过抛出错误的方法替代了该部分的方法。

第二次求导做业中的BUG：

         第二次做业在结构上并无BUG出现，但在细节上出现了BUG。在对1进行化简时没有考虑项内只有1的状况，致使将为1的项整个消去了，产生错误。这也提醒我在编写这样有必定代码量的程序时不但要注重整体的思路和结构，还要当心这样的细节之处。同时在DEBUG时要充分考虑各类状况。正是因为这样的一个小错误使我直接掉入C档，算是吃一堑长一智吧。

 

 

 

3、第三次多项式求导做业

         第三次做业相对第二次做业增长了多项式的嵌套状况，在求导上复杂度增长，没法只经过4元组的形式表示全部的求导结果。同时在格式判断，项切割等各个方面增长了难度，须要考虑括号等各类新的因素。程序类图以下所示：

 

 

个人程序将可能出项的结构状况大体归为3类，包括多项式类(Poly)、项类(MPoly)和因子类(Subpoly)。在多项式类中我大体进行了3项工做，包括多项式的空格以及符号检查，对多项式中项的划分以及将项的求导结果进行整合，造成多项式的求导结果。在项类中我大体进行2项工做，对项进行分割造成因子，同时将因子求导结果进行整合，造成项的求导结果。在因子类中进行2项工做，包括对因子格式的检查以及对因子的求导。在这3类以外为了方便区分系统EXCEPTION以及格式错误2种状况引发的WRONG FORMAT!，我定义了一个自定义异常DException.

因为第二次做业考虑对于扩展的需求，在这一次做业中我成功复用了第二次做业全部格式判断函数以及部分求导函数。但这一次做业在细节上仍然有不少不足之处。个人思想仍然没有完全摆脱C的限制，在第二次做业中一样没有使用类的继承以及接口等JAVA特性的功能。同时能够从类图中看到，我没必要要的属性以及类内部分方法的复杂度仍然太高，这都是我在接下来亟需转变的问题。若是仍然将本身的思想局限于面向过程当中我势必会遇到瓶颈和障碍。

第三次做业BUG：

在第三次做业中因为我的能力和时间有限并无对整个多项式进行化简工做，所以相比前2次做业在化简时的BUG，我这一成功经过了全部强测案例。同时为了不没必要要BUG的出现，我在另外一方面增长了最终表达式的复杂性，方法是将全部的+转变为+1*,负号转化为-1*，但却忘记考虑了一种特殊状况，即将 sin(-23)转变为sin(-1*23),致使了互测时BUG的出现。这也提示我在编程时要从实际出发，若是一直使用这样的小聪明一定会致使意外出现。

第三次做业总结

         在第三次做业中我成功实现了对前2次做业的扩展，经过递归以及进一步的划分类的方法实现了嵌套求导。但在类继承、接口实现这些JAVA特性结构的使用上仍然有很大的不足之处，同时并无实现最终的化简工做。

4、关于互测屋和DEBUG

         我对别人的DEBUG方法相对而言分为2步。第一步即在本身编写程序的过程当中将可能出现的BUG记下来，而后在互测时攻击别人，其中主要包括格式错误以及可能出现的爆栈错误。例如空串，1,1-1,0*x^0等这样的常见错误。一般这种方法特别有效，将近70%的错误均可以经过这样的方法解决。第二步就是阅读他人的代码。因为要阅读将近7我的的代码，没有时间一行一行读，我采起的作法是挑选重点读，一般是匹配的正则表达式，求导过程以及最终的化简步骤等几个场景爱你犯错误的地方。经过这2步的配合90%的错误都能被找到。

在3个星期的互测中，经过阅读他人的代码我也开拓了眼界，学到了很多东西。包括工厂函数，以及优秀正则表达式书写等各项新的知识。同时也促使我充分检讨本身糟糕的代码风格。

5、Applying Creational Pattern

         因为使用JAVA仍然不够熟练，在3次做业中我都没有充分考虑到重构的问题。三次做业的求导过程都大相径庭，所有重写。但格式判断函数，即对空格以及加减号合法性判断获得了复用。

6、总结

    通过了3个星期的多项式编程，我初步掌握了JAVA的编程方法和面向对象的基本思想，目前仍有2项不足之处，首先个人思想仍然很大程度上收到C的限制，老是想经过面向过程的方法解决问题。第二是对JAVA语言的部分特性不太熟悉，当别人接口，继承，工厂函数很是熟练时，我仍然在把JAVA当C写，使用多个函数定义想解决一切问题，这显然是不合适的。在接下来的学习和编程中我须要充分认识到本身的不足，从他人的代码，网上以及课堂上充分学习，使本身成为一个合格的JAVA程序员。