面向对象前三次作业总结

　　第一次写博客，不足之处还望海涵。完成了三次独立的编写java程序的过程，稍有感悟，将其记录再此。

第一次作业

　　1.Metrics量化分析

　　好吧，看起来有些复杂，那么肯定是存在些问题的。

　　2.UML类图

　　这里并没有附上类图，因为只有一个main函数和一些方法。

　　3.自己的BUG

　　作为一个java新手，而且上一个学会的语言还是典型的面向过程式的C语言，我犯了一个大错误，就是整个程序只用了一个main函数和一些方法，写成了一个不伦不类的java程序。第一次作业由于只为了完成，故而没有太在意面向对象这一重点。整整一百多行的main函数，相当有C语言面向过程的风格。

　　4.别人的BUG

　　在分析别人的bug时，我是按照直接判断非一般数据的原则进行的。因为一般的数据在公测中已经通过，所以没有多大必要进行测试。我着重分析别人bug的点在于：数据大小是否符合规格、数据结构的压力测试（是否存在越界问题）、已经符合规则的符号或字符异常出现。此外，在处理完以上bug的时候，我按照Readme对其代码的部分做过逻辑分析并根据此来测试bug。前者没有发现bug，倒是后者很容易发现bug。因为前者是随机测试的，就算是对某一方面的测试，也会因为数据规模太小的原因无法完全测试。而后者则可以直接track其逻辑思路并找到其逻辑方面的bug。

　　5.心得体会

　　作为java新手，刚开始真的很不适应面向对象，但此次作业之后我又做了多次练习，终于还是将基础的类的运用基本掌握了。从面向过程到面向对象的转变还是有成效的。

　　而在一开始接触本次作业的时候，我是直接忽视了正则表达式的内容，用状态机来操作字符的，但可惜的是没有成功，后来经过别人点拨才直到要用正则表达式的。以后这种情况还是不要出现了，真的费时费力不讨好。

　　此外，因为没有运用类的原因，我对于多项式并不是分隔开进行模块化管理的。我的思路是：首先读取第一个多项式，存入结果数组，然后变不管多项式的存在，直接根据运算符号将项与结果数组做运算。这样的结果自然是代码长度和复杂性的增加以及可读性的丧失。

第二次作业

　　1.metrics量化分析

　　2.UML类图

　　这次因为运用了类进行管理，所以有了类图。该类图的箭头指向的含义是具有支配关系，当然并非是对属性的修改，而是在上一级的类中会运用到下一级的类初始化对象。例如在Requestqueue类中定义了Request的二维数组的数据结构。

　　3.自己的bug

　　这次作业我的bug还是蛮多的。首先，我没有搞对数据的范围。因为要求的是int的范围，故而我直接定义int类型的数据，过大的数据有long类型读取并筛去。但是本次因为不允许有负数出现，正数的范围直接大了一倍，所以我的边界数据压力测试没有过去。其次我对数据结构大小的规模含糊其辞，我注明指令可以超过100条，但因为我的数组大小只有1005，所以被别人用3000条的指令运行崩溃了。还有就是我的中文没有用规定的UMT-9国际标准编码，虽然测试结果不会有问题，因为中文只在#后出现，但还是被有心人发现了。最后一点，是一个目前仍具有争议的bug，虽然我不认为这是一个合法的bug。当两个++号同时出现在一个数前面是，我是直接判错的，但是检测者认为这是一个合法的bug，因为我的Readme中并未出现相关说明。对此我抱有疑问，因为两个++号同时出现在一个数前面应该是一个常识性的不合法的串，当然也可能是我的原因，别人察觉到了这个点而我没有察觉，在Readme中没有提到而直接在程序中报ERROR。

　　4.别人的bug　　　　

　　对别人bug的分析我仍然是按照先测试非常规数据，再分析逻辑思路的。此次并未查出任何错误。但是当我将我的bug测试他的程序的时候，他也与我一样对++进行了ERROR处理，并且其Readme中也未提到，这让我对我的bug有了深深的怀疑，++难道真的是一个非常识性需要注明的bug吗？

　　5.总结

　　这一次的作业我完全按照指导书来做，该有的类出现了，该有的功能与属性也具备了，虽然有些并未在此次作业用到。不过我的程序很明显的一点是顶层的类只负责调度不进行任何操作性的处理，所有细节类的处理被划分到了底层的类中。这样一来我的程序看起来就是类与类的大小不均衡，有些类只有5、6行，而有些类多达150行。这样的结果恐怕也是我在设计之初没有考虑到的问题。可能这样的结果也是被允许的，毕竟类与类的功能不同，规模自然也不同了。此外，本次作业中许多属性并未用到，出于下一次作业的考虑，我将其保留了下来。

第三次作业

　　1.Metrics量化分析

 　

　　2.UML类图

 

 

　　3.自己的bug

　　本次作业基于上次作业完成，所以所有细节之处都已改正，并没有什么输入输出类的bug。但是，从UML类图上很明显的看出，我定义了调度方法的子类，但是并没有运用，因此也没有什么interface接口，toString重写后也没有用到。我没有用子类的原因在于一开始我对于子类的构造方法有着很深的误解，一直无法解决，索性直接在原代码上增删修改，最终有了incomplete的bug。

　　4.总结

　　首先，对于子类的构造方法，现在我已经很明确解决方法了，只需要在子类的构造方法下加上super(父类构造方法)即可。

　　其次，对于private的属性，用return返回其值需要单独设一个方法，这样子如果一个类有多个需要返回的属性，则会变得很麻烦，但目前我找不到更好的解决方法。

　　最后，java里没有unsigned char类型，所以我在解决上一次的int的bug时不得不使用long类型或者干脆使用double，这样造成很大的内存浪费，因为很多处都要修改为占存更大的类型，我想可以在设一个类，将无法表示的unsigned数据通过模运算映射到int的正数部分。