oo作业总结报告

oo第一次博客 

  以前从未真正的写过Java代码,接触Java也只是寒假的时候简单的看了看语法,不懂该如何面向对象,但没事,心里不惧,想着什么都是可以学的(直到真正开始写工程的时候,才发现自己还是太天真了),就这样开始了OO学习这条不归路。

一、三次作业的实现过程分析  

第一次作业

  第一次作业是多项式加减运算,首先我用c语言写了一遍,基本熟悉题目的具体要求,当用Java去写时,我遇到了下面一系列的问题(具有难度等级):

        1. 该如何划分类,如何面向对象编程;

        2.正则表达式是什么;

        3.该如何用Java来实现(语法知识);

      什么都不懂,那就只好去找资源了,花了一整天的时间去看教学视频、Java教程、上网搜索博客,快速了解Java的基本语法,还有正则表达式的基本用法,但面向对象是个什么还是感觉很迷糊。这个时候最有效的办法当然是和大佬进行交流交流了,在我舍友的帮助下,我脑袋里逐渐有了清晰的设计模式,但是不是面向对象就是另外一回事了,最后事实证明,就是面向过程。

  类图

  

  度量

  

 

第二次作业

  第二次作业相对第一次较好一些了,但对于使用面向对象编程还是不太灵活,感觉自己的类划分不太合理,很不均衡,但又迫于时间的压力,最后不得不动手写代码;

  面临的问题:

  1.类的划分与交互问题(花费时间最长的工作了);

  2.指导书的真正含义,感觉很难懂了;

  3.调度算法问题(选择什么算法);

  根据要求主要分了电梯类,楼层类,请求类,请求队列类,调度类。

  类图

  

 

  度量

  

 

第三次作业

  第三次作业也是一个挑战(其实每一次OO作业对于我来说都是很大的挑战了,笑哭),从傻瓜电梯到A Little Smart 电梯,增加了可稍带功能,可我却不是仅仅就添加了可稍带功能,我将第二次的代码全部重构了,心血历程了。

  当我重新看我傻瓜电梯的代码时,我意识到其实自己还是在面向过程编程,对于类的职责的划分非常不均匀,导致某些类规模较大,而有些类却寥寥几行,并且发现自己当初对于每个类的功能和属性的认识还不够到位,为了后续代码的可扩展性,于是毅然决然的重构了所有的代码,将各个类的属性和功能都做了较大的调整。

  类图

  

 

  度量

  

 

相对于第二次作业第三次作业做的改变:

  1.电梯类继承于接口,有了up和down方法,并且有对于电梯内请求的处理,使得各个方法间者职责划分更加清晰;

  2.楼层类添加了对于楼层请求的处理;

  3..根据实际情况,请求都是从电梯类和楼层类中发出的,于是我就模拟了这种行为,将从控制面板中读到的请求交给楼层和电梯,然后再由楼层和电梯交给请求类,进行处理分析,最后再交由请求队列类,进行处理;

  4.将程序入口从调度器中分离出来;

  5.调度器中写了两个主要的方法,判断同质和判断捎带,避免了第二次作业中全部都在主函数中处理的情况,尽量将功能进行封装;

 

现在看来第三次作业的缺点:

  1. 主函数还是显得冗长,并且调度器承担了较大的职责;

  2.觉得判断同质不应该放在调度器中,可以放在请求类中,这样凡是进入请求队列中的请求都是可执行的请求,请求队列也就不会因为同质而再进行改变,提高其独立性;

  3.代码风格不太严谨,会显得比较丑,有阅读障碍;

 

对三次作业度量结果的分析

  三次度量结果是具有共性的,所以这里放在一起说明了。可以看出main和调度类圈复杂度比较高,主要原因在于其中的if,while逻辑较为复杂,但是对于输入的判断条件确实很多呀,也不知道怎样再减少了。其实这里有个问题搞不明白,对于多个&&条件,是写在一个if中好,还是写多个if_else if 好,在效率方面有区别吗,还是说只是代码风格观看上的区别?

 

二、  BUG分析

第一次作业  

  由于输出错误信息的内容与标准输出不一致,挂了十几个点,怕是没有像我这么菜的人了吧;

  数据过大而导致的crash,当时并不知道还有try_catch这种操作,强烈建议写try_catch;

  在设计的时候没有考虑到数据过大的问题,底下测试的数据也都较小,故出现了此种错误;

第二次作业

      第二次作业互测和公测都没有bug,也许是吃一堑,长一智吧,主要原因还是课下的测试样例比较充分,但也许还存在什么未知的错误,不过是现在还没找出来罢了。

第三次作业

  公测挂了十一个点,其中十个点是因为输出的错误信息和标准输出不匹配导致的,我也是万般心痛了,自己辛辛苦苦熬夜的成果,却被这样的低级错误全部毁掉,也许痛了才会长记性,只能安慰自己幸好这样的错误在这个时候及时的出现,而不是在以后工作时出现的。互测没有被测出bug,但其实当天我就发现了自己代码的另外两个bug,公测也没有测出来(其实感觉第三次公测挺弱的),最后又花了一天时间来找自己程序的bug。

自测

       自己程序的bug大多数是因为课下测试不充分,没有按照分支树去构造样例,而是通过自己对自己程序的了解,在脑中构造可能会出错的样例,进行测试,并且在构造样例时,一些逻辑性不强的部分是通过逻辑来进行检查处理的,并没有构造简单的样例去进行测试,这样也许一些较为低级的错误就不易被发现,而逻辑复杂的错误又没有想到,然后就gg了。

互测

       进行格式测试, 如果对方用的是正则表达式,我会先检查其正则表达式,否则的话再根据分支树进行测试。

       进行功能测试,先是简单的进行基本功能测试,再进行边界测试,压力测试,在这几次测试中都找到了对方的Bug。在测别人程序时,我曾尝试去看懂对方的代码,从而在逻辑上找到错误,但并不是每个人写的程序都那么好懂,看了三份也就只找到了一个bug,但可以大致上知道对方的思路,从而学习借鉴思想和方法。

 

三、第一阶段总结

  记不得是谁说过的一句话了“人生就是不断的否定昨天的过程”,每当回看的时候总是会发现问题,而这些问题却是当时很难发现的,这也就说明了总结的重要性了。

  . 类图还是提前画画比较好,会使结构更加清晰;

      . 设计是要占用大量时间的,每次最难的地方也就是设计了;

      . 多和大佬交流交流,但并不是说不动脑思考,而是学习好的方法和思路;

      . 课下测试根据分支树进行测试,但并不是说分支树就一定是全面的,测试是个无限逼近的过程吧,多测测总没坏处,尤其是边界问题;

      . 设计代码结构的时候应该想到可扩展性,要不然后面可能会走的很难;

      . 不断的总结错误,改善代码,其实发现每当要添加新的需求的时候才发现原来代码的一些问题,设计问题或是风格问题等等;

 附上自己每次做OO 的过程:第一件事就是先学习该部分的理论知识;第二件事就是研读指导书,看客服群和issue上的讨论,尽力达到对指导书要求的深刻全面的理解,但却也是很容易心累的事情了QAQ;第三件事是构思自己程序,画出类图,属性方法,以及类之间是如何交互的。

  感谢OO,打不死你的都让你变得更加强大!

posted @ 2018-04-03 18:39 N.S.A 阅读(...) 评论(...) 编辑 收藏