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，打不死你的都让你变得更加强大！