一、对面向对象的理解
在大一学习python的过程中，接触了一些面向对象的思想。在三月伊始，java的面向对象编程就成了我的主要任务。对我来说，面向对象编程就好像装修一个房子，我根据各种家具的特性和功能实例化很多真实存在的家具并且摆放到合理的位置上，我知道他们可以实现什么功能，但我们不需要知道它的内部实现是什么样的。这是一种封装的思想，实现一种高内聚和低耦合的状态，它很好地提高了编程的效率。java语言还有一个继承的特性，表面上看，它改善了编程中代码重用的冗长感，而更重要的作用是，它构建了一个完整，清晰有条理的体系。
二、三次作业的度量分析
1、多项式计算
图一 多项式计算类图
Poly用来生成多项式对象和多项式计算，ComputePoly包含主方法和对多项式的解析。结构比较简单，清晰。
度量情况如下：
图二 多项式度量结果
可见，ComputePoly 类中的复杂度和嵌套会比较多，究其原因，parsePoly方法中虽然使用了正则表达式，但是在识别各个格式错误上还是使用了控制流语句，并且没有设立专门的异常类，出现很多代码复用的情况。
另外，此次作业也用面向过程的方式实现了出来，具体是通过状态机完成的，这种方式下结构很紧密，对于这样小一些的工程还是可以实现，若工程规模一大，结构就会不清晰，不易调试。面向对象就会让整个结构比较清晰，各司其职。
2、傻瓜调度式电梯
图三 傻瓜调度式电梯类图
总体结构也较为清晰，是以Scheduler为核心的电梯体系，其中Floor类中包含main方法和输入请求的筛选。筛选后实例化Request类并且加入请求队列，进而在Scheduler类中处理队列，直到队列为空。具体处理过程交由Elevator类中的方法。
度量情况如下：
图四 傻瓜调度式电梯度量
可以看出，主要问题出现在Floor类中，很显然，在main方法里放入很多格式筛选的条件是不恰当的。与多项式中的问题一样，使用了很多控制流语句来区分各个格式情况对复杂度影响很大。
3、ALS调度式电梯
图五 ALS调度式电梯类图
结构较之于作业二没有本质的变化，与第二次作业不同的在于新创建了一个捎带集，对于被捎带请求有一套不同的运行方法。
度量情况如下：
图六 ALS调度式电梯度量
Scheduler仍是整个程序的核心，而SchedulerExtend是继承了Scheduler，override了其中的方法并且新加了属于自己的方法。电梯的运动方式用接口归纳了起来。复杂度等方面和第二次作业的问题是一样的。
三、遇到的bug
1、正则表达式的错误
忽略了前导零的存在。以及在第二次作业中楼层上下限的问题。
这些都是同学由于正则表达式不正确导致的。因为我始终对自己的正则表达式不放心，于是只在第一次作业中分区块使用了正则表达式（结果就是控制流太多导致程序复杂性加大），但是正则表达式确实是一个值得好好学习的内容，在java文档中可以看到很多通过正则表达式完成的方法。还要了解每个方法对正则表达式的使用，不然很容易踩到这个方法的坑。例如，match方法中的贪婪匹配需要加-1参数。
2、对忽略请求没有考虑全面
第三次作业中，看到同学对相同请求仍然执行的情况。也就是对同质请求的判断不够充分。
3、对使用方法的不熟悉
如果不加try catch，在一些方法里面会出现空引用，OutOfBound等的异常，直接导致程序的崩溃。
4、逻辑错误
在第三次作业中对特定情况下计算时间用了错误的基础值。
5、强制转换的不注意
四、测试程序的策略
首先，检查正常功能的实现是否有误，主要是在临界值上面进行测试，然后进行压力测试。观察使用到的函数，在查阅文档后对这些函数进行特殊值的测试。最后查看代码关键部分的逻辑是否有误并且构造特殊的测试集。
五、感触
丰富的内置函数确实让开发变得轻松，再加上java5的一些新特性，使得java开发与之前的C语言开发有很大的不同，现在最大的问题还是在于如何进行统筹的设计，以及一些算法的设计上面，若是一些方面没有考虑成熟就会导致代码的可扩展性很差，并且一个不好的算法在后期调试的时候会带来很大的麻烦。在设计算法的时候先要做好情况的化归和归并，还有就是在后期扩展，新增一些要求的时候也要让它跟原本的程序融合在一起，否则这种缺哪儿补哪儿的方式会让程序冗长凌乱还易出错。