OO第四单元总结

本单元架构设计

　　　这一单元要求实现UML图的解析器。我的类图如下所示。

 

　　    一些主要的处理方法有以下几条：

　　　1.为了方便统一管理，我将自己的接口类以及自己的Class类用一个接口统一管理，方便实现相关指令时可以统一进行。

　　　2.将类图、时序图和状态图的有关信息的存储以及指令的实现分别下放到各个图自己的类中，这样主解析器内就不会出现行数过多的情况。

　　　3.对于抛出多种异常的指令，采取逐级抛出的思想，一来无需在第一级就存储极多的信息来方便查询，二来逻辑比较清晰，不会出现抛异常顺序错误的情况。

　　　4.对于自己缩减的官方包的类（如MyClass， MyUmlState），内部的第一条属性便是对应的官方包的类。方便在后续扩展需要更多信息是进行扩充。

　　　对于具体的指令实现部分，基本上全是暴力方法，这三次作业CPU时间给的十分充裕，所以没有进行算法的优化。

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

　　在第一单元中，我所认为的架构设计就是将一组相关操作包装成一个类。换而言之，类似于面向过程的编程中的将过程封装成函数的感觉。但是整体的思维上仍然是面向过程。那时候所认为的OO方法，不过是C语言中的“struct” + 函数。

　　在第二单元中，整个题目更具有面向对象的感觉。这一单元我更注重不同类之间的独立性，高内聚，低耦合。因此在那个单元，除了第三次作业中我忽略了一个死锁的问题花费了不少时间debug，其它的作业基本上很顺利的通过。

　　在第三单元中，我们自己实现的主要是容器的选择以及有关算法的训练，在这一单元我主要学习了官方提供代码的架构。在之前所学习过继承，实现等概念，但是我并没有太多感触(毕竟我前两个单元也很顺利的进行了扩展)，但是在这一单元去我发现这有助于有关元素的统一管理和处理。

　　在第四单元中，我将第三单元中的感悟进行了实践，有关的处理确实方便了许多。

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

 

　　第一单元，我采用的是自己编造数据进行测试。现在看来那似乎是最容易写评测机的单元，但是由于时间的原因再加上自己对自己的代码很有信心，所以没有写评测机。于是第一单元后两次作业bug频出。

　　第二单元，我开始搭建评测机测试。取得了不错的效果，而且在互测时同屋的bug都能找到，只不过由于复现问题有些没有成功抓到。

　　在第三、第四单元中，依旧使用评测机。但是同时更多的采用静态分析，因为后两个单元的作业官方架构已经提供好，在有评测机做出基本的正确性保证之后，我通过阅读自己的代码来保证自己的每部分设计确实实现了自己的要求。现在看来，这确实是行之有效的。

总结自己的课程收获

　　现在的我不禁想起了两年前上荣老师课的时候，老师经常提起的“高质量完成两千行代码”的话。因此在上这门课之前，我就知道这一定是一场硬仗。但是实际动手操作起来，我又觉得，这一切似乎并不难。每周的思索学习和测试似乎渐渐成了一种习惯，在不经意间，OO课程结束了，我的工程能力以及测试能力也得到了提升。尽管网络上充斥着学生们对他不好的评价，但是在我看来，这门课真的非常好，他对我而言的锻炼是全方面的，以前面对大工程的第一反应是不想下手，但是现在总是静下心来思索架构。而学长们的博客和指导书的建议也给了我很大的帮助。相比较于OS，OO给我的感觉是简洁明了，我知道我该干什么，实践出真知。现在再次翻看自己最初几次的代码，心中有着不亚于自己最初写出“hello world”时的成有感。OO，真的让我学到了很多。

立足于自己的体会给课程提三个具体的改进建议

　　1.在讨论区中有关指导书的答疑部分，建议进行分类，比如第四单元可以按照指令进行分类。这样在有问题的时候不用翻看整个评论区，直接进入对应的分区即可。如果没有再进行提问。我发现许多同学会提问前面已经问过的问题。

　　2.建议在互测中增加这样一项功能：在被别人hack到之后可以有2-3次上传代码的机会，当然参加互测的仍然是原先的版本，只不过在互测信息栏再显示自己后上传的代码对应的用例错没错。在我的两次互测被抓的互测中，我都被hack十多次，但是在当时根本不知道自己究竟错了几个点。这样一来鼓励同学还是尽量自己发现bug，二来也能让减少内心的焦虑感。

　　3.实验的正确答案和成绩建议公布。