北京航空航天大学2019年OO课程第四次总结

0.前言

这是第四次OO课程的总结博客了，也是最后一次博客作业。本单元的作业重点在于uml，需要我们学习uml的相关知识，才能正确写出程序。

1.本单元两次作业的架构设计

 第一次作业就是理清UML类图中各个元素的关系，主要是类和接口，但是我没有把类和接口分开开类，导致代码过长，所以另开了一个MyUmlUnit的类。

第二次作业在第一次作业的基础上增加了顺序图和状态图的相关操作，我分别开了一个新类，MyUmlState和MyUmlColl；另外，新增了三个有效性检查，由于第一次作业的MyUmlClass过长，因此我新开了一个类MyUmlClass2。

 

2.四单元架构设计及OO方法总结

第一个单元的多项式计算中，我们开始学着用面向对象的程序解决数学问题。在这个过程中，我们实现了各个类的封装。第一次作业主要的难点输入的处理（通过正则表达式），这方面在后面就没有体现了，后面都是使用的助教提供的现成的接口。另一方面，要求性能时数据结构的选择也显得十分重要。最后，第三次作业让我对于接口和继承机制有了初步的了解。

到了第二个单元的电梯调度，我才更加认识了面向对象程序设计的强大。通过面向过程来实现一个实时运行的电梯系统是非常困难的，对我们来说是不可能完成的。面向对象可以。在面向对象中，多个对象在多线程中复杂的交互与信息传递起到了巨大的作用。通过第二单元的作业，我们对于设计模式也有了了解，知道了提前规划的重要性。

第三个单元的主题是JML，这几次作业我们需要按要求实现接口的JML规格。第一次的任务还相对比较简单，第二次的任务在第一次上并没有太大的提升，但第三次作业里实现对现实中地铁换乘的相关操作还是比较困难的。这个单元主要学习了规格，同时认识到了规格在多人协作的项目中起到的重要作用。

第四个单元的主题是UML。通过学习UML，进一步学习了建模的思想。类图也对如何理解java中类的封装起到了辅助作用，顺序图和状态图也对我理解面向对象编程起到了辅助作用。

我学习到的oo方法和思想是从实际问题到抽象。从最基本的封装、继承、多态，到后面的多线程以及设计模式，最后到规格设计和构建模型，一步步地抽象成模型。

3.测试的理解与实践

测试在我看来主要分为两部分，一部分是强测前测试自己的程序，另一部分是测试在互测中测试别人的程序。

这两部分是相通的。自己的程序，一旦能够通过中测，想要再通过读代码来找程序bug是很难的，我能想到的办法就是自己构造完备的测试数据，构造的数据真正完备了，就一定能测试出所有的bug，但是构造完备的数据很难，并不能保证自己构造的就是正确的。所以，应该熟练使用Juint等现成的办法来测试。互测的时候就是把测试自己程序bug的方法一一应用到他人的程序上，在用完所有的方法后再去读他人的代码，看看还有没有其他问题。

第一单元的测试，我都只是构造了一些特殊的样例，在第二单元才开始学着构造较为完备的样例集，在第三单元学着使用Junit等方法。

4.课程收获

1.经过了oo的洗礼，我的抗压能力增强了。除了博客作业周以外，oo排满了整个周的时间，同时还要在这个时间中抽出时间去处理其他科目的学习和作业。对于我这样完成作业耗时长的人来说，压力十分巨大。

2.对于java的基础知识、多线程、JML规格以及UML等内容有了较为系统的认识，并能够进行初步的应用。

3.学会了使用功能强大的IDEA来调试程序，减轻了我很多的工作任务，虽然这似乎也会对功能强大的ide产生依赖，但是这确实大大地提升了生产效率。

4.学会了如何协调各个科目的学习，如何安排紧张的学习时间，并适当的劳逸结合。

5.三个建议

1.听说16级周五的理论课和实验课是错开的，也就是上一周理论课上涉及的东西下周的实验课上才有有相应的作业，而到了我们这届不知道为什么就变成了上午讲的东西下午上机就要用，虽然后来助教收到反馈后给出了提前给出内容让我们提前学习的解决办法，但是毕竟治标不治本，有时候内容给出的也并不那么及时，所以还是希望下一届同学们上课内容和下午上机错开，这种乘热打铁只是想当然，因为有时限要求，如果没有时限还能在上机的过程中逐步学习，否则即使是学到了东西，但是分没拿到，并不那么让人开心。

2.我们上课PPT的部分内容偏向总结式的学习，其实并不那么适合初学者，每次学习ppt完了收获不大，需要自己另行先去找资料学习才能弄懂。虽然之后再看ppt会有不少收获，但是事实是ppt常常就是我们的第一手学习资料，这样并不友好。要么就课上从基础的内容讲起，不然讲了也没有用，要么就直接硬性要求课下先自己把基础的东西学了，不硬性要求的话大家平时的作业都挺多的，再做完其他事以前大概是不会提前自学的。（仅代表我这样的菜鸡选手）

3.互测的bug修复有一种情况是很难受的，一份样例测出了程序的多个bug，导致无法合并修复，也不能一部分一部分的修复，只能非合并修复，当这样的样例个数小于等于合并bug数时没有什么问题，甚至还可能站便宜，但是如果此时有个狼人针对这多个bug一起多次重复提交bug，那么提交了多少次样例都会算多少分。这是我在第三次测试里确实碰见了的情况。