第四单元博客总结——暨OO课程总结

第四单元博客总结——暨OO课程总结

第四单元架构设计

第一次UML作业

简单陈述

第一次作业较为简单,只需要实现查询功能,并在查询的同时考虑到性能问题,即我简单的将每一次查询的结果以及递归的上层结果都存储下来,使用一个Boolean型变量记录是否更新过该结果,即日后查询可以直接返回查询内容,而无需再次更新,也算是一种较为无脑的办法,根据后来的评测数据以及结果来看,性能、CPU运行时间并不是该次作业的重点,正确性才是关键之所在。需要同学们对于UML每一个元素有充分的理解,同时助教也在讨论区回答大家的问题,通过阅读讨论区也可以做到初步了解。

接口包中给出了各式UMLXXX类,即各种UML元素,但个人并不是很看得懂其中的一些Json部分代码,选择自己构建一个MyUMLXXX类,其中存储UMLXXX,以及各类查询方法还有属性,由于是自己写的类,用起来更加自如,也不用怕有什么坑存在。

在MyUmlInteraction类中,首先是对输入信息的分类处理,较为简单,只需要注意不同信息的处理顺序不同,这样就可以实现在新建数据之初,就实现例如属性和方法存入对应的类中等。个人认为本次作业中较难点为获取顶级父类,存在递归向上查找父类的问题,然后就是同样复杂的实现接口列表,在这里我都选择使用递归实现,而并没有用图的知识来结局,但事实证明早晚要用到图的。。。

类图

方法复杂度

类复杂度

同时我才用了一个以空间换时间的小技巧,也就是同时存了id2Class, name2Class, class2Id三个HashMap,以帮助我快速找到对应的class或id。

第二次UML作业

简单陈述

第二次作业在上次的基础上,增加了类图的检查,以及顺序图和状态图,个人认为难点主要在类图的三个Rule检查上,但万万没想到在顺序图的查询中,吃了读题不仔细的亏,并没有意识到message可以传递给endPoint,直接导致报错。。这是后话。

新增加的三个Rule分别是元素容器中不能有重名成员,不可以有循环继承以及任何一个接口不能重复继承另外一个接口。重名成员较容易判断,但需要注意的是重名对象不仅限于属性之间,关联对端之间,属性和关联对端之间也不可以有重名出现。而循环继承较为复杂,需要用到图的知识,我使用邻接矩阵来记录相互之间的继承关系,并通过tarjan的强连通分支算法,寻找循环继承。而第三条规则,重复继承,我也是建了一张图并通过BFS,寻找重复继承。

除了StandardPreCheck类以外的,顺序图和状态图查询,都与之前的类图查询差不多,甚至更加简单,在此就不多加阐述。

类图

方法复杂度

类复杂度

四个单元架构设计及OO方法理解的演进

  • 第一单元中,求导问题,虽然一开始就知道后期可能会出现更加复杂的求导问题,但个人的架构设计仍然存在缺陷,导致三次作业重构三次,并没有做到任何的代码复用性,但也开始尝试面向对象的编程理念,分成多个类,先考虑对象而非编程过程。

  • 第二单元中,老师讲授了一些设计模式,如读者-写者模式,工厂模式,生产者-消费者模式,电梯的代码开始出现复用,但由于功能较多,仍然存在部分代码重构的现象,对于每次提出的新要求,都需要大量代码的改进,开始尝试各种设计模式。

  • 第三单元中,学习了全新的JML,虽然个人感觉代码内容与JML关系不大,但也体会到了工程上如何对于功能提出要求,底层的程序员如何根据已设记好的架构,完成代码编写,JML只关心方法的pre-Condition以及输出,具体实现并不关心,学会了写JML,为日后在工作上的发展打下基础。

  • 第四单元,UML的出现,自己封装UMLXXX,统一继承UMLElement,并将功能分化到各个类来完成,而不是一个GeneralInteraction搞定所有功能。

四个单元中的测试及理解

  • 第一单元,那时的我并不懂得太多测试相关信息,互测阶段只能靠个人手动造数据,且通过一次打开八个Project的方法,手动输入数据,采用笨拙的方法进行比较,效果并不理想,也只能通过一些特殊情况来卡bug,而隐藏在代码深处的一些隐蔽bug无法检测出,

  • 第二单元,多线程电梯,导致检测更加困难,这时开始学会使用python自动化造数据,由于多线程,无法与他人匹配输出,也只能检测一些抛出异常或是直接crash的bug,正确性检测并不多,但也开始走向自动化检测。

  • 第三单元,已经开始尝试手写脚本,搭建弱版评测姬,也第一次体会到了出门去吃饭,让电脑在宿舍跑bug的快感,但突然发现时间不够啊,(造了10w组数据,跑不完了。。。

  • 第四单元,由于传入数据是mdj文件生成,并没有太好的自动生成方法,测试数据也只能靠手画,且没有互测也就只需要验证自己的正确性。

课程收获

个人较为喜欢OO这门课,但真的很遗憾没有获得任何奖项,甚至鼓励奖。。我也为这门课付出了许多汗水,大二下学期的生活格外充实,但烤漆也格外舒适。且万万没想到的是最后一次作业翻车,出现了读题失误。之前的单元作业,除了第一单元因为性能分无法拿到满分,以及第二单元电梯出现两次bug,其他作业都是满分,但强测测出bug真的很伤。。。也是第一次上这种工程性极强的课程,每一周都和打仗一样,完成一次大作业,但到后期也逐渐熟练了,甚至开始期待下一次的作业,会自己进行猜测,也十分喜欢每次完成代码后的优化过程,虽然有时候是反向优化,但个人代码能力确实有了极大提升,已经可以两天完成上千行的代码工程,并完成bug调试,测试代码的能力也实现了突破零的飞跃,之前从未接触过自动化测试,也被互测逼迫了去学习测试,学习自动生成测试数据,感觉OO真的給我带来了很多。

三个改进建议

  • 首先希望通知能够更加醒目一点,就比如间隔微信群啥的,个人感觉站内通知特别容易被忽略,可能是我个人问题。。。

  • 多线程单元的测试,希望能增加次数,或是开放评测姬来跑一些数据,感觉自己在评测姬上会出现一些不可复现的bug,甚至可能是只有在评测姬上才能跑出的bug。

  • 感觉研讨课的参与,讨论气氛不是很明显,但我也不太懂怎么提高,主要是大家还是较为害羞,比如我就害怕自己的一些想法或问题过于低级,但在网上也确实没有找到解决办法,还是不太放的开吧。

  • 感觉JML单元,可以更加偏重JML一点,我们同学间开玩笑,只有最后写但愿总结的时候,才开始真正的了解JML语言,真正的思考一些细致的问题,之前的时间都用在写程序,实现功能上了。

  • 希望OO的实验课程能够有所进步,感觉前几次的实验课程都很乱,且考察上午刚讲授的内容,基本是在机房现场学习ppt,现场尝试,现学现卖,个人认为调整到周一而不是刚上完课就上机会比较好。 

猜你喜欢

转载自www.cnblogs.com/JordenQiao/p/11079538.html