OO_Unit4_Summary暨课程总结

初始oo，有被往届传言给吓到；oo进行中，也的确有时会被作业困扰（debug到差点放弃）；而oo即将结束的此刻，却又格外感慨这段oo历程。

一、单元架构设计

本单元任务是设计一个UML解析器，能够支持对UML类图、状态图和顺序图的分析，并能够通过输入相应指令来进行相关查询和模型的有效性检查。总的来说此单元作业只要准确理解了各个元素之间的关系和其拥有的具体属性的含义，此单元的作业难度会下降很多

第一次作业

此次作业是完成对UML基本的类图解析并支持部分查询功能。

在正式动手写此次作业之前，我花费了很大一部分时间去完成对类图元素其属性的含义理解，并认真分析了一下各元素之间的层次关系。不得不说在理清了这些问题之后，程序的框架设计和最终完成都简单了很多。

我重新写了部分元素类，增加其对下级元素的包含和具体查询功能；对于部分”最底层“元素和查询并未涉及的元素就直接运用了官方提供的元素类（有点偷懒的嫌疑hhh）。同时在这样涉及架构之后，我将UML类图分析器 UmlInteraction的查询功能逐层分散下去，逐级反馈，再分析器类中只需很少的代码即可完成查询。但是我将类图构造方法和顶层查询方法都放在了UmlInteraction类里，导致该类代码十分冗长,在超行的边缘疯狂试探。

但是我不得不说，在程序层次和结构上下足功夫之后，后续的迭代是真的舒服。我的后两次作业即在此基础上进行迭代，极大的节省了主体程序编写时间。

第二次作业

此次作业是在上次作业的基础上，增加对状态图和顺序图的解析，并支持对二者的查询。

此次作业如法炮制完成第一次作业的顺序和思路，先分析各元素之间关系，再分析元素旗下各属性的含义，最后完成建模。

有了第一次的基础，这次作业完成的很快。由于状态图虽然和类图有点关系，但是由于查询时不涉及该部分内容，于是我讲状态图有关数据单独存储。

而且还是有一点是将建模方法和查询方法都放在MyUmlInteraction类中，而且此次是真的在500行的边缘完成的作业（捂脸.jpg)

第三次作业

此单元是增加对类图、顺序图、状态图的规则检测。

在基本保持原有架构不变的基础上，由于MyUmlInteraction类是真的放不下，于是我重新开了一个MyData类，用来构造和存储数据，Interaction从data中获取数据，然后调用数据的自身查询方法进行查询。此单元我是因为对“对端”的意思理解有误，导致中测重复提交。同时由于其他事情太多，所以并没有对此次程序做过多测试，不过幸好强测没有翻车。

本单元由于在第一次作业完成时便设计了一个可以说是四个单元以来最好扩展的架构，所以在后两次作业的迭代扩展时，完成的相对比较轻松，体验感很好。

二、四个单元的总结

第一单元：主要是针对多项式的求导和优化。

• 该单元主要是在学习继承和多态的基础，对项和表达式进行抽象来设计架构。虽然我这一单元运用到了继承和多态，但是由于不够熟悉继承和多态，同时思想还停留在面向过程编程阶段，所以继承和多态运用的十分别扭，导致架构极为丑陋，冗余代码太多，丝毫不具有可扩展性和迭代性，所以我真的次次重构。
• 同时由于此单元还考察正则表达式和WF的判断，所以我其实大部分精力花在了解析表达式上，最后不仅表达式解析写的极为复杂，而且架构也没时间细究导致十分丑陋。

第二单元：主要是电梯载人问题

• 该单元主要考虑多线程并发的问题。学习和掌握多线程锁的占有和释放，一旦某个细节没有处理好，就很容易出现死锁问题。同时也由于多线程的不可复现性，找bug的难度极具升高，当然我一般都是出现问题然后理论分析锁的情况，相比之下还是比较容易发现问题。
• 而程序的整个设计架构，依托生产者--消费者模式和WorkerThread模式展开，体会到了相关设计模式的优越性。

第三单元：JML语言学习和理解

• 这一单元可以说是很难，但也可以说是很简单。只要理解并且掌握了JML语言的基本语法，完成作业就会很容易，毕竟程序框架已经由课程组用JML搭建好了；但是如果不能够理解JML语言，那么完成本单元的作业就会有很大的难度。同时也深切的学习并且感受了一下契约式编程的优点所在。
• 当然这一单元的学习不仅仅是JML语言的学习，也包含了对已有框架和数据的抽象，抽象出图模型，并且还顺带复习了诸多图算法。

第四单元：UML图的理解

• 在理解UML类图、状态图、顺序图的基础上设计完成相关图的建模与搜索。该单元重点内容即为理解相关类图模型，并且设计一个容易查询的层次架构。总的来说，难度不是很大，但是理解模型元素的含义和注意规则检查细节是十分重要的。

四单元总结：对比我第一单元作业架构和第四单元作业架构，能够明显的感到自己的成长变化，架构不在是随心所欲，想到哪写到哪，而可以是有序的、可扩展的。同时在对问题分析层面，也不再是依据题意而不加以抽象和分析的情况。也学会了将功能需求下发，而不是在顶层模块完成所有操作。以及接触并运用了多种设计模式，学习了契约式编程、防御式编程的思想，真的收获颇丰。

三、测试理解和实践

• 众所周知，oo是一门考验java程序能力、python编程能力和shell脚本编写能力的总和科目。第一单元的自动化测试，在讨论区大佬的指导之下，通过python造出了自己的评测机，大数量的随机数据的测试有效的提高的程序的准确性，同时也帮助我在互测中有效的发现同组人的bug。第二单元类似，但是由于并发的“不可复现性”，所以帮助有限。第三单元，我通过评测机和室友们的程序一起对拍确保正确性，收效十分明显。第四单元到是自己纯手撸数据进行测试，数量和覆盖范围有限。在写评测机的时候，自学了很多python知识和shell脚本知识，附带效益明显hhhhh。当然我比较难受的是，评测机全部自己手撸，应该和室友一起合作写的，这样就不会浪费很多时间在写评测机上面了（捂脸.jpg)。
• 其实写评测机中出数据时，也是考验自己对题目的综合理解，什么样的数据才是有效的，什么样的数据才能进行有效覆盖，极端数据自己是否考虑完整等。在这一方面我还是有所欠缺，数据大多采用随机生成，白盒测试量偏少导致程序在强测时出了点小问题。

四、课程收获

• 首先当属于抗压和互测抗卷能力，自己在程序设计的思考能力和思考模式。虽然不能说自己完全脱离面向过程思维，但是自己在面向对象思维和思考肯定是得到了长足的进步。在写程序之前有了思考程序架构这一过程，不再是拿着题就开始莽了。
• 在具体指示点方面，包括优秀架构的学习，多种设计模式的理解与运用，JML和UML的学习与应用，面向对象中的多态和继承方式，多线程并发的理解和实际操作。在技能和思想方面都学习到了很多新的知识。
• 同时，在讨论区和课堂上，与大佬同学和老师的交谈中，特别是在研讨课上，了解并学习了大家的思考方式和研究思路，极大的丰富了我的见识，对我来说很有启发意义。
• 最后是程序的测试，初步的了解到了对程序正确性和鲁棒性测试方面的一些知识，有助于我从测试方面来审视我的程序。当然也包括附带学习的python和脚本知识（虽然都很浅hhh）。

五、建议

• 整体来看，我觉着第一单元的作业难度偏大，在初识oo时，在还保留着面向过程编程思想的时候，就来写出对构架有一定要求的程序，存在很大难度。而且最终结果，以我为例，就是现在都不忍心回去看当初的那个程序。我觉着可以出那种有一定思路和架构要求，但是又不高的那种题目，让大家在初期即可体验到面向对象的优势所在。（或者是在最后阶段可以让大家重新用一学期所学知识来写当初的作业，重点找出和体会两次架构和设计上面的不同和变化，来体会各自的oo收获）
• 实验方面，确实不公布答案和结果有着课程组的顾虑，但是从我们的角度来看，不知晓实验的正确结果，我们也不知道当时实验时的认识是否正确，实验的效果得不到体现（此处我认为，实验和作业是两个几乎不同的方面来加深自己对课堂内容认识和理解的方向）。还是希望有一定反馈，让我们自己对比以确实自己的认识正确与否。
• 互测方面可以进行一定的改进。互测几乎最后都变成了评测机的比拼，我几乎是没有一次能够读完互测屋的代码。我认为可以减少互测屋的人数，不用从代码分份数上面打击大家读代码的热情，更不用说互测屋里层次不齐的代码了。也可以在互测时推出互测屋里代码架构推优标记，进行推优和被推优的人皆可在互测时得到一定加成，激发大家热情。

六、线上教学

• 最大的好处在于，在任何不懂的时候可以翻看视频，反复的去加深理解。但是也正因为这个好处所在，导致在课堂时间的专注度就不够，导致翻看视频的时间浪费（当然这些都是自己自控力弱的原因orz）。
• 课堂讨论时间，因为当初选课时并不知道oo的课堂讨论会激烈到占用下节课的时间，所以在周二oo结束之后又选择了其他课程，导致为了上其他课，而极大的影响了oo课堂讨论。
• 线上课堂，真的没有课堂学习的氛围，所以无论是录播课时间还是研讨课时间，总感觉课堂有一丝别扭，从而达不到理想的学习和交流的效果。
• 除了以上几点之外，oo课程总体的体验感是非常好的，老师和助教们都积极的解决大家的问题，弥补线上的一些不足。而且oo的大部分时间还是自己思考课堂知识点，思考作业架构和完成作业上面，所以也可以说线上对oo的影响很有限。

从某乎上也理解到了部分以前oo课程的评价，但是作为一个刚刚体验完oo课程的人，我只想说，不管以前的oo课程怎么样，至少现如今的oo，是你6的绝世好专业课之一，丝毫不逊色于你6的计组等课程，来体验和感受刺激就对了！此处也感谢老师和助教们的辛勤付出，让我们能够拥有如此完美的oo体验！！！