OO课程总结

拈花ヽ惹草 提交于 2020-01-14 13:22:43
  • (1) 第四单元两次作业架构设计

  • (2) 四个单元中架构设计及OO方法理解的演进

  • (3) 四个单元中测试理解与实践的演进

  • (4) 课程收获与总结

  • (5) 体会与建议

一、 第四单元两次作业的架构设计

1、第四单元第一次作业架构设计

需求分析:本次作业要求简单的对已经解析过的UML类图进行归类查询操作的实现。因为解析的前置操作都已经被助教爸爸实现,我们只需要将已经解析好的各个对象进行规整即可,由于进行的查询操作比较繁琐,将数据进行归类使查询的操作变得简单就变得更加重要,因为感觉数据的量不是很大,就没有向第三次作业一样进行数据缓存。

将类相关的参数封装到一个类中,如 : 类的属性参数,类的操作,类的继承,类的接口实现;将操作相关属性封装在属性类中,如 : 类中的参数;这样可以帮助快速查询。

 

具体如上,构造函数在Myinit类中实现,主要用于构建各个元素之间的关系。

2、第四单元第二次作业架构设计

需求分析:第二次作业增加了顺序图和状态图的属性分析,并另外加入对于模型有效性的分析,具体实现思路和第一次并没有特别的地方,由Myinit类实现构造函数,因为这次作业的查询涉及的操作类似图,所以这部分的东西我就用图的形式来存储的,因为顺序图和时序图的具体属性的归属性并不是很强。所以这部分我没有将属性归类到一个结构之中,而是将具体的查询操作封装到不同的类中,最后通过组合的方式拼接在一起,具体的图如下。

图中Check用于三个模型的检测,MyUmlSequene为顺序图的具体操作, MyUmlStateChartIntegration为状态图的具体操作,MyUmlGeneralInteraction是最后的组合结果,继承上一次作业的最终类以保留上一次已经实现的操作。

二、四个单元中架构设计和OO方法的演进

1.第一单元作业

第一单元的时候对于面对对象的概念还没有完全理解,程序的整体感觉就是用Java语言写着以前自己C语言方法实现,只是将结构体换成了类。第一次、第二次作业的对对象的提取要求还不是很高,但是到了第三次作业的时候经历极其痛苦的重构,但是对于面向对象的理解更加深刻了,自己对于程序的整体架构也更加重视,自己认为对于后面的程序设计打下了不错的基础。

2.第二单元作业

第二单元是多线程的程序设计。回顾整个OO,这一部分自己感觉是相对最难的,需要学习的东西有很多,既要熟练掌握多线程并行知识和线程安全控制,还要对电梯的调度算法要求有很好的性能,对于程序的扩展性也有很高的要求;但是我个人感觉这一部分也是我个人收获最多的一个单元。自己对于对象的提取和封装有了很大进步,并且开始尝试用一些程序设计模式使整个程序的扩展性更强。尤其是在对算法性能的探讨中,我对于java的各种数据结构的了解有了很大飞跃(第一单元我还只会用ArrayList,在这个单元我对于各种LIstSet结构使用场景,以及为了了解线程安全而去阅读其实现原码);总的来说,虽然难度挺大的,但我觉得这是让我提升最大的一章,也是最充实、游戏体验最好的一章。

3.第三单元作业

第三单元开始OO的重心转移到了架构设计之上了。本单元的课程主要通过阅读JML代码注释实现一部分功能。这一部分我们的工作重心就转移到了如何使代码架构更利于查询操作,这个部分的话感觉比较虐心,虽然没有性能分,但是自己总害怕自己会因为性能不够错点,因为这样的性能不够出现错点的话最后debug的时候也没办法去弄,就让自己陷入了一个无休止想提升性能的深坑,结果最后每次出来的时候时间会有很多富余,自己做了很多多余的其实不需要的优化(没有也能过的);这个单元的整体感觉就是主要是程序架构设计能力有所提高吧,但是提高的也不是太明显,因为主要心思都放在性能上了(当然好的便于扩展和操作的架构性能也不是问题,但是我打一坨??出来也能跑的比较快),最后看到助教爸爸放出来的标程感觉自己的架构能力还是差的很远,还是需要多多学习。

4.第四单元作业

第四单元的话总体来说……,感觉自己有点烂尾的意思,也是到了学期末,开始忙着考试了,自己就有点懒(貌似大家都是这个样子的说),也是主要就是如何设计架构的问题吧。这个单元自己的架构自我感觉挺方便的,不需要什么动脑子的操作,就是结构体提取好的话就是很方便,性能方面也没什么太大的需求;这个单元收获最大的话就是UML图的读写能力的提高了吧,其他的感觉自己真实摸了。 ( = 。 = )

三、四个单元测试理解与实践的演进

整体来说OO课程让我意识到面向测试的重要性吧。对于第一单元开始就是中测过了就摸了,不再进行很多特别的测试,但是第二次作业就吃了个大亏,自己在优化的时候打错了一个字母导致整个程序崩盘,这是我开始洗心革面认真测试了,这里是自己对于测试认识的第一步吧。但是这个时候自己测试的能力还是很有限:当然首先就是普遍性的正确性测试,对于简单的输入模型进行测试;之后就是寻找边界条件的问题,第一个方法就是认真读指导书,然后在脑中模拟可能出现的情况,去挖掘其中存在的坑点,然后再去检验。其次就是对于输入数据的不普遍的极端边界条件进行测试。在互测的时候我也是采用了这样的策略,将我认为的易错点放在其他同学程序上测试。但是发现这样真的很低效,然后自己和舍友开始合作搞比较简单的评测姬去测试,同样发现这里面的问题是评测姬也只是对普遍的正确性进行测试,基本摸不到什么边界条件,所以最后在测试上演变成了以下几步:1、评测姬开始测试,自己跑然后和舍友程序对拍测个几小时,没问题就进行下一步。2、特殊情况测试,这一部分就是我和朋友们脑洞大开瞎想奇奇怪怪的边界数据点。结合以上两种方法进行测试。也是后面我一直采用的模式。

四、课程收获与总结

在本门课程中收获很多吧,首先最浅显的就是熟悉了Java语言吧,然后就是java设计程序的一些思想,使用了很多很多的工具帮助自己,对程序的测试和其他方面的了解都更加深刻了;还了解了很多很有用的帮助代码规范性的工具如JML和UML,最重要的收获还是面向对象的思想收获以及程序设计的思想吧,这些东西不仅仅限于java语言,对于我的程序能力的提高真的是有很大的帮助。

五、体会和建议

我的建议主要是在游戏中的一些不好的体验吧:

1、一个房间7、8个人有点多;采取7、8人同房的挺棒的,也许老师和助教们的目的是让我们看更多的代码设计以获得更大的收获;但是我个人认为这个应该没起到老师们期望的效果,因为实际操作上代码过多,很难很细致的去了解每一个同学们的设计思路(课程开始的时候自己认真看收获有一些但是太耗时了),个人认为主要是时间问题吧,大家的主要想法都是找Bug上(我选择劳动生产率更高的评测姬),人太多的话对于评测也造成了很大麻烦,期望助教们能够单开一个模块或者窗口来详细帮助大家构建类似评测姬的评测手段。

2、Bug修复环节,强测错的点后面修复还会扣分; 这里我可以理解助教们期望这个机制起到鞭策同学们修复BUG的想法。但是强测前面已经扣过了,后面还要再扣一次感觉真得很伤,我觉得可以采用强测bug和互测bug分离,强测bug修复后不扣分,不修复照常扣分的机制,感觉体验会好很多。

3、有关实验课和理论课。实验课是让我觉得最懵的地方了,自己上午刚上完还没太懂,下午就上,结果实验课也懵,感觉没起到很好地效果(当然这个时间安排和教务处也有关系)。我个人希望实验课的要求能够更加明确一点吧。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!