OO前三次做业总结

1、对面向对象的理解

　　在大一学习python的过程当中，接触了一些面向对象的思想。在三月伊始，java的面向对象编程就成了个人主要任务。对我来讲，面向对象编程就好像装修一个房子，我根据各类家具的特性和功能实例化不少真实存在的家具而且摆放到合理的位置上，我知道他们能够实现什么功能，但咱们不须要知道它的内部实现是什么样的。这是一种封装的思想，实现一种高内聚和低耦合的状态，它很好地提升了编程的效率。java语言还有一个继承的特性，表面上看，它改善了编程中代码重用的冗长感，而更重要的做用是，它构建了一个完整，清晰有条理的体系。

2、三次做业的度量分析

一、多项式计算

图一 多项式计算类图

 

Poly用来生成多项式对象和多项式计算，ComputePoly包含主方法和对多项式的解析。结构比较简单，清晰。

度量状况以下：

图二 多项式度量结果

 

可见，ComputePoly 类中的复杂度和嵌套会比较多，究其缘由，parsePoly方法中虽然使用了正则表达式，可是在识别各个格式错误上仍是使用了控制流语句，而且没有设立专门的异常类，出现不少代码复用的状况。

另外，这次做业也用面向过程的方式实现了出来，具体是经过状态机完成的，这种方式下结构很紧密，对于这样小一些的工程仍是能够实现，若工程规模一大，结构就会不清晰，不易调试。面向对象就会让整个结构比较清晰，各司其职。

二、傻瓜调度式电梯

 

图三 傻瓜调度式电梯类图

 

整体结构也较为清晰，是以Scheduler为核心的电梯体系，其中Floor类中包含main方法和输入请求的筛选。筛选后实例化Request类而且加入请求队列，进而在Scheduler类中处理队列，直到队列为空。具体处理过程交由Elevator类中的方法。

度量状况以下：

 

图四 傻瓜调度式电梯度量

能够看出，主要问题出如今Floor类中，很显然，在main方法里放入不少格式筛选的条件是不恰当的。与多项式中的问题同样，使用了不少控制流语句来区分各个格式状况对复杂度影响很大。

三、ALS调度式电梯

 

图五 ALS调度式电梯类图

结构较之于做业二没有本质的变化，与第二次做业不一样的在于新建立了一个捎带集，对于被捎带请求有一套不一样的运行方法。

度量状况以下：

 

图六 ALS调度式电梯度量

Scheduler还是整个程序的核心，而SchedulerExtend是继承了Scheduler，override了其中的方法而且新加了属于本身的方法。电梯的运动方式用接口概括了起来。复杂度等方面和第二次做业的问题是同样的。

3、遇到的bug

一、正则表达式的错误

忽略了前导零的存在。以及在第二次做业中楼层上下限的问题。

这些都是同窗因为正则表达式不正确致使的。由于我始终对本身的正则表达式不放心，因而只在第一次做业中分区块使用了正则表达式（结果就是控制流太多致使程序复杂性加大），可是正则表达式确实是一个值得好好学习的内容，在java文档中能够看到不少经过正则表达式完成的方法。还要了解每一个方法对正则表达式的使用，否则很容易踩到这个方法的坑。例如，match方法中的贪婪匹配须要加-1参数。

二、对忽略请求没有考虑全面

第三次做业中，看到同窗对相同请求仍然执行的状况。也就是对同质请求的判断不够充分。

三、对使用方法的不熟悉

若是不加try catch，在一些方法里面会出现空引用，OutOfBound等的异常，直接致使程序的崩溃。

四、逻辑错误

 在第三次做业中对特定状况下计算时间用了错误的基础值。

五、强制转换的不注意

4、测试程序的策略

　　首先，检查正常功能的实现是否有误，主要是在临界值上面进行测试，而后进行压力测试。观察使用到的函数，在查阅文档后对这些函数进行特殊值的测试。最后查看代码关键部分的逻辑是否有误而且构造特殊的测试集。

5、感触

　　丰富的内置函数确实让开发变得轻松，再加上java5的一些新特性，使得java开发与以前的C语言开发有很大的不一样，如今最大的问题仍是在于如何进行统筹的设计，以及一些算法的设计上面，如果一些方面没有考虑成熟就会致使代码的可扩展性不好，而且一个很差的算法在后期调试的时候会带来很大的麻烦。在设计算法的时候先要作好状况的化归和归并，还有就是在后期扩展，新增一些要求的时候也要让它跟本来的程序融合在一块儿，不然这种缺哪儿补哪儿的方式会让程序冗长凌乱还易出错。