oo做业总结报告

oo第一次博客　

　　之前从未真正的写过Java代码，接触Java也只是寒假的时候简单的看了看语法，不懂该如何面向对象，但没事，内心不惧，想着什么都是能够学的（直到真正开始写工程的时候，才发现本身仍是太天真了），就这样开始了OO学习这条不归路。

1、三次做业的实现过程分析　　

第一次做业

　　第一次做业是多项式加减运算，首先我用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 好，在效率方面有区别吗，仍是说只是代码风格观看上的区别？

 

2、  BUG分析

第一次做业　　

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

　　数据过大而致使的crash，当时并不知道还有try_catch这种操做，强烈建议写try_catch；

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

第二次做业

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

第三次做业

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

自测

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

互测

       进行格式测试， 若是对方用的是正则表达式，我会先检查其正则表达式，不然的话再根据分支树进行测试。

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

 

3、第一阶段总结

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

　　. 类图仍是提早画画比较好，会使结构更加清晰；

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

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

      . 课下测试根据分支树进行测试，但并非说分支树就必定是全面的，测试是个无限逼近的过程吧，多测测总没坏处，尤为是边界问题；

      . 设计代码结构的时候应该想到可扩展性，要否则后面可能会走的很难；

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

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

　　感谢OO，打不死你的都让你变得更增强大！