oo前三次作业总结

第一次作业:多项式算法

 1. 度量分析

oo前三次作业总结

 2. 作业类图

 oo前三次作业总结

 

 3. 程序分析

  在动手写第一次作业前,“面向对象”和“面向过程”两个名词在我眼里还是一对孪生兄弟——毕竟都是敲代码实现设计,到底有什么大的不同?

  第一堂课,老师反复强调,所谓“面向对象”,就是以数据为中心。类是实现对象的模板,类与对象的区别好比是一张空白的电话簿页面和一张记录了某些特定信息的电话簿的区别。面向过程是针对过程分析进行编程,面向对象的重点则在于根据模拟场景构建需要的实体,为这些实体设置属性、并围绕它们的属性构建一系列操作方法。

  说到这里就有些明白两者的区别了,真正动手写程序则是在把这些概念性的东西吃下去后,真正开始消化的过程。

  第一次作业完全是新手入门,跟着老师的步伐磕磕绊绊的走,照着讲课用的ppt里的类图分析一模一样的设计。本次作业构建了两个类:多项式类Poly和记录并计算多个多项式的Main类。通过与C语言实现方法的对比很容易便能发现两者的不同。收获:学会了使用超级好用的正则表达式匹配字符串(c使用正则匹配需要额外下载regex.h库),写Java代码的能力简直三天速成。

4. 主要问题

  在字符串匹配时由于正则表达式书写复杂,字符串过长可能引起爆栈(StackOverflowError),解决方法是将匹配过程拆分成两次。

 

 

第二次作业:傻瓜电梯

 

1. 度量分析

 

 oo前三次作业总结

2. 作业类图

 oo前三次作业总结

3. 程序分析

  第一次作业在构建每个类时均把其属性设置为private,但在每个类中又各自设立了访问和修改这些属性的getset方法。个人认为getset的频繁使用可能弱化了private存在的意义,本次作业类比较多,对应状态也比较多,频繁使用private的状态变量需要创建多个getset,所以程序中所有类的状态变量都设置成了默认的default属性,在同一个包中可以相互访问。

  实现电梯运动有5个类:电梯Elevator,楼层Floor,请求Request,请求队列ReqQue,调度器Scheduler。主类Main中的main函数是程序入口,此外,还有若干表示电梯(请求)状态(如上行下行、楼层请求/电梯请求等)的枚举变量。

  调度器中schedule方法和command方法代码规模相差较大,还需要改进。 

4. 主要问题

  对“第一个有效请求起始时间必须为0”的判断出现了逻辑失误,不能判断大于一个的因为时间不为0造成的无效请求。解决办法:新增布尔型变量ist0记录t的时间状态。

 

第三次作业:ALS电梯

 1. 度量分析

oo前三次作业总结

 

 2. 作业类图

oo前三次作业总结

 

 3. 程序分析

  第三次作业是在第二次作业的基础上进行改写。由于将傻瓜电梯变为ALS电梯多了一项“捎带”要求,进而引入了被捎带请求的同质过滤问题,我对第二次代码做了一些修改,从调度方法schedule中提取出过滤同质的代码使之成为独立的rmsame函数,同样能被子类继承调用。

  主请求的来源有两种,一是队列头,二是上一主请求执行完毕后捎带队列中未执行的ER请求。这两种情况都需要构建主请求自己的捎带队列,故在ALS_schedule子类中实现了lookBring方法。

  除此之外,本次作业中关于对象状态变量的访问写的十分混乱:有时选择为其建立单独的getset方法,这样如果需要改变状态属性需要改动的代码范围小;有时又选择直接用对象加“.”引用,因为这样访问简单快速……今后作业中应在设计时确定属性,避免混乱访问的情况发生。

 4. 主要问题

  应解决的主要问题大概有以下4个:如何判断捎带请求、如何过滤捎带请求的同质请求、如何处理同一楼层多条请求执行结果的输出顺序问题、如何挑选升级成为主请求的捎带请求。这些问题在实际解决过程中往往是相互关联的,极易发生补好这个bug又出现另外的bug的情况。在修改代码不幸改到代码混乱逻辑也混乱的情况下,针对错误分支树构建合适样例能够发挥不错的侦察作用。

 

关于bugdebug

  自己的程序比较难发现逻辑错误,个人而言还是跑测试样例比较容易找到bug。找到bug之后,凭借自身对程序结构的熟悉程度,定位出错点一般不算太难,debug就是对逻辑漏洞打补丁了。

  别人的程序:一般不看代码直接跑样例很难把别人的bug揪出来,个人认为要想找别人的bug,还是要先分析代码,至少了解大概的计算逻辑,在逻辑不严密的地方构造针对性强的测试样例(结合被测程序的代码设计结构来设计测试用例),发现bug的概率会更大。

  总结:前三次作业在结构分析、程序测试上比较重视,公测和互测中第二次作业由于起始时间判断条件错误出现了bugbug位置和设计结构并无太大关系。

 

心得体会

  除了第一次作业结构比较简单,接下来的两次电梯模拟实现结构更加复杂,需要考虑方方面面,代码长度也从100行左右一跃而至四五百行,规模大的代码出现问题更加难进行错误定位和调试分析,因此清晰明了的设计结构有帮助且十分必要。

  每次作业下发都会伴随作业指导书,在动手写代码之前把指导书的要点提炼出来、到讨论区逛一圈把需要注意的点记录下来、然后进行类结构规划和逻辑功能模块划分、最后用Java代码实现功能,工程化的工作流程能减轻不必要的负担,机械化的实现过程对我而言更能规避错误的发生。

  Java修炼过程任重道远,路漫漫兮,而吾辈上下求索矣。