OO第四单元总结

OO第四单元总结

第四单元架构设计

第四单元主要是实现了UML类图解析器，针对输入的UML类图以及查询指令来输出相应的信息。主要的难点在于阅读源码和分析UML类图各个参数的对应关系，在第一次作业中将所有容器和方法实现都放在MyUmlInteraction类中，通过一次遍历分开存储每一种UmlElement，再根据各种元素的特点实现每个方法。

在实现方法的过程中对容器有大量的遍历，实现了getClass、hasFather等方法分别判断类与其父类是否存在或冗余，分别其他方法复用。由于第一次作业内容较多，采用最简单的遍历计数导致代码繁冗，在第二次作业增加实现了MyState类、MyStateMachine类以及新增的顺序图、状态图类来存放容器和方法，这些类并不是将UML类图实例化，而是将解析器分类，在实现方法时根据解析的种类来使用不同的解析器，使得耦合度降低，并且方便调试。这种架构更为适合迭代，因此在第一次作业的架构设计上有不足之处。

第二次作业在第一次作业的基础上增加了顺序图和状态图，同样难点在于阅读源码和理清UML类图各个参数的关系，除了解析器的分类外没有其他的改动。第三次作业在烤漆就摸了。

对架构设计及OO方法理解的演进

由于是重修OO，所以从第一单元开始就大概了解作业的难度以及怎样使用OO方法来编程，也有意识地去思考便于迭代的架构。例如在第一单元最重要的一点就是学会用OO方法来建立每个类的关系，将表达式转化为树结构，再理解了递归下降就不难了。第一单元的OO方法主要体现在继承，不同函数类有大量相同意义的方法，通过继承可以将不同函数类用一个父类统筹起来，在使用时就能体会到继承的方便之处了。

在面向对象编程的过程中，我逐渐有意识地将一些属性和方法封装成类，每个类维护自己的数据和方法，一个方法通过不同层的类层层调用解耦，每个类都只需要解决自己的问题，这样也避免了代码太长的风格问题。

对测试的理解与实践的演进

我在测试上一直做得不是很好，大部分时间都放在写代码本身，以及大部分的测试都是自己编数据，并不常用到手搓评测机和对拍。

测试的目的是发现代码的bug，在这几个单元里我的测试方法都是构造基础功能实现的数据后，再测试一些边界数据，而自主编写的数据太难测出bug，因为在构造的时候想法跟写代码时差不多，导致一些异常情况无法覆盖。所以最后趋于面向评测机测试。

当然，自动化的测试是非常有必要的，虽然在OO作业中没有经常使用JUnit单元测试，但是在某软工课上没少进行单元测试，单元测试的好处是在迭代开发的过程中如果进行了某一部分的修改，能很快地发现这一处修改带来的bug，并且基础功能的实现很容易得到保证，不需要再进行构造简单数据，也给bug修复的过程带来便利。

课程收获

第二次的OO旅程非常的充实且有趣，主要是充实，在另外一门OO2.0课程的摧残下，OO是多么甜蜜蜜。我在饱受折磨的同时也感受到了快乐，比如我的憨憨轮询电梯在第三次作业强测突然得到很高的分数，有一种凹出效率的成就感。在完成OO作业的时候基本上是自己埋头，虽然测试没做足强测总是寄，然后就是最后一次作业刚好在烤漆集中的时候没有完成，除此之外我对本学期的自己还是很满意的。在部分单元作业修改了之后，我仍然可以完成得不差，弥补了很多去年的遗憾，也感受到自己在更加认真后也是能够完成一些事情的。

改进建议

一学期下来对实验课没有什么印象了，唯一想吐槽的点是UML类图的选项纵向排列且很大，这让找不同选手非常折磨。

pre的通知如果可以找导员帮忙通知一下就好了，这次pre是在开学完成的。

希望可以记录下来每次提交的通过情况，以及查看每次提交，而不是只能提交某一次并查看上一次。