第四单元博客总结——暨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，现场尝试，现学现卖，个人认为调整到周一而不是刚上完课就上机会比较好。