目录
一、本单元架构设计
- 第一次作业
- 第二次作业
- 第三次作业
二、四个单元总结及对OO方法的理解
三、测试理解与实践的演进
四、课程收获
五、课程改进建议
六、线上OO课体会
引言
第四单元是OO课程的最后一个单元，主要目标是在理解UML语言的基础上设计一个解析器，把读取的信息以合理的方式存储，并按照指令输出获得的二次信息以及进行规则检查。本单元博客除了介绍第四单元的设计思路之外，也会回顾并总结整个OO课程的学习经历。
一、本单元架构设计
1.第一次作业
第一次作业主考察了对类图的解析。第一次作业时花费了很久才弄清楚输入文件的各种元素的含义，在设计框架时选择了一锅端做法，即在主类MyUmlInteraction中采取大量hashmap来实现各种数据的存储，这种架构理解上比较简单，但是结合后两次作业的迭代开发经历看来并不明智，我了解到其他同学采用了将class进行统一管理，并把其他信息再交给class管理的做法，层次会更加清晰，代码结构也会比较合理。
关于指令的实现：
- classOperationCount：在存储参数时，按照参数类型将参数对应的操作存进PARAM、NON_PARAM、RETURN、NON_RETURN为键的map里，如果要查询RETURN、PARAM类型的操作，只需遍历所有RETURN类型的操作，查询是否在PARAM列表里，是则计数器加一即可。
- classAttributeCount：指令查询两类，一个是SELF_ONLY，就是只看当前类里多少个，如果是ALL，就要包括继承的类里的属性。
- 找到类实现的全部接口，父类和接口继承都算。这个方法里比较难的一点是接口允许多继承，所以我一开始写成找父类的那种while时出过bug。
类图框架也比较简单，重点是理解信息该以什么方式存进map里，又怎样调用出来计算需要得到的结果：
- 这次作业由于搜索时没有做标记，因此有一个点超时了，已修复完毕。
2.第二次作业
第二次作业在前一次的基础上增加了对协作图和状态图的解析。
-
- 本次我构造了MyUmlClassInteraction、MyUMLStateInteraction、MyUMLOrderInteraction这三个类，在处理输入方面，我选择让所有的elements都分别经过这三个类的构造方法，如果是符合要求的元素则各取所需进行分析和储存。
- 在状态图里查找所有的后续状态时，要进行dfs以求得所有的后续状态。
本次作业的新增部分总体不难，重在理解，类图框架如下：
- 第二次作业没有出bug。
3.第三次作业
第三次作业多了一个规格检查的部分，总体难度还是挺大的，十分容易出bug，我当天debug一直de到截止前两个小时，下面给出我对各个规则进行检查时的思路。
- R001：对某一个UmlClass，不能含有重名的attribute或者end，这里的思想是，一个类在与另一类关联时，会以某种方式管理另一个类，与管理属性的含义类似，因此这个类对应的end不能与属性重名。具体解决时，只需要按类设计map，对应一个hashset存放，遍历到属性和关联对端时，检查是否已经contains。
- R002：不能循环继承，需要注意的是这里只考虑类继承类、接口继承接口这两种情况，分别做dfs即可。
- R003：一个类不能重复继承另一个类、一个接口不能重复继承另一个接口，同样对类和接口遍历，再做dfs即可。
- R004：一个类不能重复实现某一个接口，仿照上面的步骤先把重复继承的接口找出，再对类遍历，若类实现了其中的某接口则违反了该规则，若没有，再dfs搜索，需要注意的是这一步也要对类的顶层父类进行搜索判断是否违反规则。
- R005：查看是否有名字为null的，遍历有即修改flag为1；
- R006：接口所有属性均为public，比较简单，只需遍历即可；
- R007：最终状态不能有状态迁出，遍历transition，若有source属于最终状态的，修改flag为1；
- R008：初始状态最多只能有一个状态迁出，遍历transition，按sourcr对所有初始状态用map存放它的target，若最终某初始状态的map.size大于1，则修改flag为1。
本次作业类图如下：
- 本次作业也没有出现bug。
二、四个单元总结以及对OO方法的思考
第一单元围绕正则表达式的求导与优化展开，三次作业呈现递进式关系，每一次作业都在前一次的基础上增加需求，难度由浅入深，着重考察了学生能否应用面向对象的思维来解决问题。对于这一单元的学习，我的最大收获是更加深刻理解了继承和多态，尤其是第三次作业解析表达式部分难度对初学者而言还是很大的，这也更能push我们去寻找更灵活的解决问题的方法。
第二单元的三次作业是关于电梯问题的迭代思考。这一单元是我们对多线程问题的初次学习与接触。多线程问题中考察的重点是锁的占有与释放，处理不好就极易造成死锁；同时，由于多线程运行的不确定性，我们写代码与debug的难度都大大增加。这一单元的内容难度也挺大的，最重要的内容是对并发和死锁的理解，让我们对java处理多线程有了更深的理解。
第三单元是我跌得最重的一单元，虽然很多人都说这一单元的内容相比前两单元要简单，但我却由于时间限制等等问题出了很多bug。这一单元主要聚焦于JML规格下的代码完成与测试，考察了我们对于JML规格的阅读和理解能力，同时还考察了一些基本的数据结构和算法知识，要求我们能够使用JUnit等途径对自己的代码进行测试。
第四单元是OO课程的最后一个单元，主要目标是在理解UML语言的基础上设计一个解析器，把读取的信息以合理的方式存储，并按照指令输出获得的二次信息以及进行规则检查。难点在于理解输入的组成以及以何种方法储存数据是最清晰且代价相对较小的。
现在回顾这四个单元的学习，我可以清晰地感知到自己从面向过程到面向对象的思想的转变。比如第一单元我仍然是按照C语言习惯解析表达式，按照计算的流程去写我的实现代码；但最后一单元时我已经能学会从容器的角度去合理排布我的数据，让数据与数据之间进行清晰、有效的交互来得到我需要的答案。
三、测试理解与实践的演进
这学期的OO课程使我认识到了数据生成手段和测试手段可以是多种多样的，从最开始只会手动构造数据，到自动生成数据，再到针对第三单元的JUnit单元测试，不同的测试可能各有各的侧重点，为了确保程序的正确性，测试数据应当是较为全面的。至于检查运行结果的正确性，较为可靠的应该是与其他多名同学对拍。
除了正确性之外，还需注意程序的运行时间是否合理，是否在规定的标准之内，这里可以用到java提供的getCurrentThreadCpuTime方法来粗略估计。
四、课程收获
- 对java语言的完全不了解到现在能每周码出千行代码；
- debug能力、心理素质有显著提升，在截止时间前仍能临危不乱改新发现的bug；
- 框架设计能力的提升，以往做的都是独立小问题，这次OO课程给出都是系列性的可扩展的问题，需要我们在第一次作业时就尽量考虑到框架的合理性和可扩展性；
- 编程思想的提升，除了我们之前所熟悉的那种面向过程的思路之外，还有能通过java实现的这种相对来说更具适用性的面向对象思想。
- 通过互测、每两周一次的研讨课和网站讨论区了解到了dalao们的更优秀的问题解决思路，对我而言很有启发意义，也使我注意到了很多坑点。
五、课程改进建议
- 每个单元的三次作业之间的难度区分时大时小，比如第一单元第三次相比前一次难度提升很大，而第二单元的第二次相比第一次就没有什么难度提升。
- 实验课的正确答案希望还是能公布一下，之前助教们解释过是怕答案流传下去的问题，我觉得哪怕让老师哪怕简单讲述一下答案都可以，毕竟没有反馈就很难有进步。
- 希望中测的数据点能稍微强一点（流下被欺骗的泪水）。
六、线上OO课体会
其实我觉得线上OO课并没有影响到我们这门课的授课效果，因为这门课本身的考核方式就是课下完成每单元作业。除此之外老师们的录播课程也准备地非常认真详细，有当时没能理解的点还能多次观看录播加深理解，我个人认为效果还是挺好的。
这学期的OO课程就这样结束了，真心实意觉得这门课的考核制度、内容设计相比我们接触的其他课程而言都非常完善合理。最后要感谢这门课背后的老师和助教团队的辛勤付出，感谢我的三位室友zyh、hlx、wsq在我困惑的时候给我答疑解惑，感谢lth同学给我的很多算法上的改进建议，感谢ljh小姐姐帮我对拍帮我找bug，(｡･ω･｡)ﾉ♡！