面向对象第一次博客作业

一、 分析程序的结构

1、第一次作业

度量分析

 

自我评价

第一次作业由于对面向对象不太了解，只在主类中封装了多项式，将其余的部分都写在了main函数中，显得main函数十分臃肿，所以main函数超过范围。

2、第二次作业

度量分析

 

类图

 

自我评价

第二次作业我进行了一定的规划，做了一定的设计，对各个类的任务进行了均衡，只有调度类的代码量略多于其他几个类。至于close函数，我是在每条请求执行之前灭掉应该灭的灯，即执行完了的请求，所以没执行一条请求都会调用一次close函数，导致close函数超出范围。

3、第三次作业

度量分析

 

类图

 

自我评价

第三次作业在第二次作业的基础上添加了新的功能，由于写傻瓜电梯的时候没有考虑扩展性，我对第二次代码进行了一些修改，使得扩展性更好，以此为基础进行扩展。第三次作业中仍然出现了超出范围的函数，是因为我采用了递归调用的方法来寻找可捎带的请求，导致寻找可捎带请求的函数多次调用。

二、自己程序的Bug

前几次作业比较简单，并且开学初期空闲时间较多，在代码的构思、测试方面花的时间较多，在前三次作业的公测和互测中出现了一个Bug。

（1）在第一次作业中，由于使用每个项的系数来记录该指数是否出现过，没有考虑到系数为0的情况，所以在系数为0的时候出现了指数重复的Bug。由于第一次作业对于面向对象思想的不熟悉，分析过程是写在Main函数里的，并且使用了字符机的方式分析；Bug的主要原因是记录的实现方法存在问题，与设计的结构没有太大的关系。

（2）分析三次作业中设计结构的问题

第一次作业：由于对面向对象思想掌握不到位，仅封装了多项式，将加减的过程作为方法；除此以外，使用了面向过程的思维，将分析输入的过程写在Main函数中。由于第一次作业较为简单，虽然代码写的十分繁琐，但没有出现太多的Bug。

第二次作业：吸取第一次作业的教训，第二作业做了一些简单的规划，按照老师的推荐规划了每个类的属性和方法。按照规划来实现，但是在实现的过程还是避免不了面向过程的思维，例如，本应该将所有请求进队，在进队的过程中排除时序错误；但是我将判断时序错误放在了出队的时候，为了适应作业的要求，只好将一条请求进队之后马上出队执行，将读入和计算的过程掺杂起来，显得很不协调。

第三次作业：第三次作业只需要在第二次作业的基础上进行 修改即可，为了使第二次作业中出现的面向过程思维不影响以后的作业，我对第二次作业的代码进行了重构，并且修改了调度类中的调度函数，使得其扩展性更强。尽管如此，在第三次作业中还是遇到了不少问题，由于采用了捎带调度策略，特殊情况十分之多，在测试的时候测出很多Bug，有些Bug在设计的时候并没有考虑，所以打乱了原来的设计，在修改的时候将代码改的很乱。

三、发现别人程序Bug的策略

1、 正常功能测试

首先进行正常的功能测试，即按照错误分支树设计简单的输入，来测试程序是否满足作业所要求的所有功能。

这一过程仅仅测试了基本功能，如果对方认真对待了这次作业，这一过程一般不会测出Bug。

2、 读懂代码，根据代码设置特殊输入

其次需要读懂代码的体系结构，每个类有什么属性，每个方法有什么功能，结合这些信息以及代码的整个流程来设置特殊的输入测试Bug。

在这一步骤，如果自己和别人实现的方式近乎相同，那么则可以将自己在写代码的时候所想到的一些问题进行着重测试，但如果几乎不一样则需要重新考虑代码会在哪一步骤出现问题。因为不同实现方式易出现Bug的位置也不相同，所以根据实现方式来寻找Bug更加合理，而不是异想天开，输入一些自己认为很刁钻的请求来测试。

这一过程主要测试代码的设计和规划，从设计方式和对方的考虑范围来寻找Bug，每个人的考虑都会有不周全的地方，并且每个人注意到的特殊输入也不尽相同，所以在这一过程中，一般会找到一些自己考虑到了而对方没有考虑到的东西。同时，在阅读代码的过程中，也会了解到对方设计的思路，以及写代码的方式，对自己写代码的水平也有提升。

四、心得体会

经过了三次作业，我了解到了封装的重要性，以及面向对象的思维在编程过程中的重要性，同时我经历了从面向过程到面向对象的过渡，从完全不懂面向对象到对面向对象思维有了一定的了解。

在设计方面，首先需要有一个全面的规划，对所有的类所包含的属性和所包含的方法进行一个全面的考虑，同时考虑类之间的交互，从而在写代码的时候游刃有余，不会像第三次作业一样，出现在测试的时候发现设计时没有考虑到的情况，打破原有的设计，甚至有的Bug在已有的代码基础上十分难修改，会完全打乱原有的设计，甚至需要重构。如果设计没有很大的瑕疵，那么测试仅仅会测出一些小Bug，或者是写代码的时候出现的笔误，或者只需要小修小补即可解决，便不会涉及架构的问题，使得代码更易维护。

在Bug方面，通过阅读代码很难发现Bug，因为在阅读自己代码的时候会有惯性思维，因此应该通过各种测试来寻找Bug，这个时候分支树给我们提供了很好的思路，但是我们不能通过简单的输入来测试，分支树仅仅是一个大框架，我们我需要结合不同的分支来测试，例如第三次作业中的同质，将同质请求与分支树的其他结点结合就会构造更加严格的测试案例，从而发现自己的Bug。