随着几周的进行，OO课堂已经经历过三次课下作业。在这三次作业中，我被扣了一些分数，也发现了自己几次作业中一些存在的共同的问题。
首先以第三次作业为例分析，我程序的类图如下
一共九个类，其中Als_scheduler是Scheduler的子类，二者分别在第二次和第三次作业中进行总调度。Request类是请求类 Requestqueue类是请求队列类，负责将输入的若干请求作为队列处理。Lift是电梯类，负责电梯的处理。FLoor类是楼层类，负责生成楼层类请求。具体流程如下:
1.程序以Main方法作为入口，然后以Reader方法来处理输入并将请求添加到队列中，其中调用了RequestQueue类的AddRequst方法来处理添加操作。
2.Reader类中也处理了不符合顺序或者不符合输入格式或者数据溢出的请求。
3.在Als_scheduler类中的smarterRun方法中进行调度,该方法是Run接口中的方法的实现：
①新建一个Reader类的实例，读入输入的请求。
②判断读入的请求是否是同层移动的请求，如果是，说明不可捎带其他请求，直接
用ExecuteAndPrint方法响应该请求并输出，然后寻找并删除同质请求，将已经执行的请求从请求队列中移除。
③如果不是同层移动的请求，便针对Lift类的实例，也就是电梯，一层一层模拟电梯移动，每移动一层遍历主请求完成时间前的所有请求，判断符合时间的请求能否符合捎带条件，用AcanTakeB方法来判断，若返回True，则添加到捎带队列。遍历完请求后遍历捎带队列，如果可以在电梯当前层执行，则用ExecuteAndPrint方法响应该请求并输出，并把相应的时间推迟。直到电梯移动到主请求的楼层并执行。执行完主请求后，如果捎带队列还有请求，则把第一条升级为主请求，接着执行。
优点：对于面向对象的思维和运用有了初步的认识，流程基本上也算是清晰。
尝试着使用继承、接口和接口的实现、抽象函数等来进行编程，这很面向对象。
命名逐渐规范。
缺点：耦合度还是不够低，有些地方改起来还是牵一发而动全身，很多内容可以再抽象出来成为一个方法却没有抽象出来，这样修改起来的时候很麻烦，可能还是受面向过程的编程影响。
·对于输入的处理不好。起初我没有利用正则表达式来处理输入，而只是想着简单地使用split方法来处理输入，结果不仅多了很多行不必要的代码，而且对于一些诸如(FR,1,UP这样的输入没办法判别为无效输入。我在做的时候也没有考虑到这些，之后发现了这些问题，我学习了正则表达式的使用，在输入的处理上基本上没遇到问题，但是浪费了很多时间。
·第一次作业对Exception进行catch，却没有catch到Error这个类的对象，对于十分巨大的输入出现Error导致crash。
·第二次作业的正则表达式判断上，我对前导0和前导正号的处理有一些遗漏。
·对于指导书的理解不深。第三次作业中一些是否捎带的问题我理解似乎和指导书有出入，也没有在讨论区进行进一步探讨而是理解为自己会了，就直接导致了我一些样例的出错。
·自我测试较少。作业完成进度较慢，没有进行一定量的自我测试就提交，一些是因为自己粗心的可以避免的错误没有发现。
问题所出现的类，第一次作业在多项式输出的处理上，也就是单项式和多项式类，输出个数能超过20个多项式和50个单项式的限制，然而因为第一次作业我采用数组的数据结构，数组开得过小，导致溢出，所幸我catch到了这个Exception没有导致crash，但是也没有输出正确结果。
第三次作业只有同层的输出顺序上的BUG，没有大问题，还好。
发现别人的Bug主要还是在一些边界情况较多，首先简单阅读代码结构，如果他的代码主要逻辑没有问题，则重点关照一些边界情况，比如小数，小数的精度；或者一些逻辑上的边界情况，比如反复走走停停的电梯等。
其次精读代码，观察他人有没有一些设计上细节的小瑕疵，所以我们自己在编写代码的时候，对于细节也要细心。
总之，在我们编写代码之前，最好对于我们的这份项目，有一个整体上的结构认知，最好先画出类图和关系，再根据类图来编写代码，这样结构清晰而严谨。
在测试自己代码的时候，要怀着测试他人代码的心态来反复找错；在测试他人代码的时候，要怀着测试自己代码的心态而一丝不苟。