一、第四单元作业框架
1、UML类图解析器
（1）设计策略
作为对UML的入门，这次作业主要考察了我们对于UML类图的构成要素的解析方法，并通过这种方法加深我们对于UML的理解。
对于从UML图中解析出来的信息进行分析与汇总，实现对于UML类图的各种元素（包括类的个数、特定类中所包含的属性个数等）的查询。在做这次作业时，我将各种元素（UMLClass、UMLAttribute等）进行了分门别类的存储，使得元素能够对应所在的类，实现查询功能。
（2）类图
由于本次作业只是对于UML类图中元素的解析，所以只需要将各种元素分门别类地initial处理一下就能够实现功能，所以我只是用了一个类来解决这个问题（因此只截取了一个类的视图）。以上即是本次作业的大体框架（seekforinterfaces、seekforancestor分别是处理interfaces、class之间的继承，seek、todo分别是这两个方法的递归做法）。
（3）度量分析
2、解析器的拓展（顺序图、状态图）以及基本规则的验证
（1）设计策略
在UML类图解析器的基础上实现对于顺序图和状态图的解析，实际操作流程并没有改变，都是通过对于存储各种不同元素的相关信息实现对应因素的关联，与第一次作业类似。
而对于基本规则的验证（元素重名、循环继承、重复继承），则是本次作业的难点所在。由于第一次作业需要通过递归实现对于最顶级父类的查询，如果出现循环继承则在查询的过程中会发生死循环，所以在我们实现继承的查询时，我们必须得保证当循环继承发生时，我们要有方法使之“停下来”。
在我的设计思路中，我在发现循环继承的类（接口）时将该类的继承寻找工作停下来，并将其最直接的父类重新赋予它（保证其他类在测试是否循环继承时不受影响），并将该类从就绪队列中剔除，保证它不会干扰到其他类的寻找工作。
（2）类图
与第一次作业相比，第二次作业由于多种图的区别，我加入了不同的类对于不同的图进行了信息的初始化工作，代码量较第一次作业有了一个飞越。
（3）度量分析
二、四个单元框架的改进及oo方法理解的演进
（1）框架改进
在本学期oo课程的学习过程中，我们一共经历了求导、电梯调度、JML语言的探索以及UML工具的探索一共四个单元的学习。在学习第一个单元时，我对于框架的理解还不够透彻，程序大多一个到两个类，将各种方法都堆积在构造器中，企图以一个程序作为方法实现的全部内容，最终也造成了我的代码可塑性很差，基本上每次作业都需要重构。
而在学习二三单元时，我能够根据多种方法的实现结合成一个类，保证了代码的可读性。由于官方接口的提供，我的作业能够逐步“适应”短而精的方法实现，在代码的规范性方面有了很大的提升。但在代码的拓展性方面我的作业仍有所欠缺。例如在电梯调度的过程中，我的第一次作业（傻瓜电梯）并没有使用楼层开关门的逐级判断，而是直接令程序sleep乘客从起点楼层到终点楼层的时间，导致在后面作业中需要对于电梯升降过程的方法实现进行重写，浪费了时间也错失了锻炼实现代码可拓展性的良好机会。
在第四单元的锻炼中，我能够很清晰地使用第一次作业的类图处理方法对于顺序图和状态图实现处理，代码可拓展性有了较大的提升（当然也有较为相似的因素在其中）。能够通过继承等方式实现类的有序管理，实现了一定程度上的突破。但在命名方面仍有瑕疵，随性的命名方式使得我在读自己的代码时都会遇到不知道方法或是变量是干什么的窘境，这也是我在接下来的代码编写过程中所需要注意的。
（2）oo方法理解的演进
在学习这门课的最开始，我以为oo是实现处理某个具体问题的课程。所以在我的潜意识里，能够最准确地实现所需要的功能就是一个好程序。
所以我在前两次作业中堆积“屎山”代码，只为了能够在一个类中实现所需要的功能。然而对比强测组内其他同学的代码，我发现我自己似乎更喜欢读他们的代码？在代码的可读性上，我发现我存在着巨大的问题。
然后就是第二单元以及第三单元，一个是对于电梯调度时间的限制，一个是对于程序CPU时间的限制，让我明白了程序的性能也是程序好坏的重要评判条件。只追求正确性并不能做出一份好的代码。
oo（面向对象）让我们学习了如何去实现一个需求，让我们知道了封装、继承和多态，也让我在实际写程序的过程中主义代码的可读性和延展性，养成了良好的写代码习惯。
三、测试理解与实践的改进
在本学期的面向对象课程中，每次作业的评判有中测和强测之分。中测的样例较为简单，并不能支持我们一定能够通过强测。所以做好数据的自我测试也是重中之重。
所以我知道了如何去使用对拍器。通过对拍器中数据的自动生成，我可以不用再像求导的前两次作业一样自己去苦心积虑地编写数据，而直接由计算机实现数据的自我测试。从第一单元的第三次作业开始到第三单元结束，我的代码充分享受到了对拍器的“红利”，也在正确性方面有了一定的保障。
然而从第四单元开始，UML文件特殊的输出方式也让我很难实现对拍器的生成。所以手绘UML图成为了我在这个单元测试的关键。考虑极端、边界情况是我在画这些图过程中所最需要注意的地方，也是我在测试过程中的难点所在。
通过四个单元的测试以及自我测试，边界、极端情况永远是一个合格程序能否实现优秀的重要决定因素，对拍器在这方面也有一定的短板（很难造出十分极端的数据）。所以在自己测试的过程中，做好自己对于这些情况的判断，是我在debug过程中的一大理解与体会。
四、课程收获
从一个在学期开始对于java（需要学习的语言）、idea（需要使用的工具）近乎一窍不通的状态，到能够熟练使用idea写出千行代码而很少犯错，我在这个学期得到了很大的收获，但是在细数这些收获时，我却又不知道该从什么方面说起。
可能在我看来，最大的收获就是教会了我应该如何去看待自己所写的代码。仅仅实现了所需要的功能是不行的，在这个性能十分重要的时代里，如何简化自己的代码，实现程序的快速运行和所占空间的优化，也是我们在编写程序过程中所需要注意的。
同时，我一向不太注重的代码风格在这个学期的面向对象课程学习过程中也得到了很大的优化。由于之前的数据结构、计算机组成等课程更加注重一个程序功能的实现，代码风格从来都不是我们学习成绩的影响因素，所以我在写代码时也经常会十分随性。但是当面向对象设置了我们作业的规范要求并设立了多人互相交换检查作业的机制时，我也才意识到自己的代码风格对于别人的理解以及程序后续的开发工作是有多么的重要，也能够在每次作业中都细心检查自己的代码风格，养成这一良好习惯。
授人以鱼，不如授人以渔。Java语言的学习在我看来反而并不是这个课程最大的收获。oo课程的一大优点就是他所教的内容在我们今后的学习过程中都有用，而不仅仅在java这一个方面。从对拍器的搭建开始（有用python），到研讨课上的分享，自己去尝试新鲜的东西才能保证我们在计算机领域的不断进步，也能帮助我们这些菜鸟快速成长。
五、对课程组的建议
（1）上机内容的调整
本学期的上机前紧后松。从一开始是上午刚讲新知识点，以及下午要求编写实现某个功能（以这些新知识点为基础）的代码，难度太大并且在我看来也没有什么实际的练习意义；到后来有把难度降得过低，只需要认图说话就能做完实验，交一份能够通过编译的程序也成了走形式的一个项目，似乎也是不太妥当。如果能够将上机内容在早上上课时提前告知，让我们在听课的同时能够揣摩上机题目，或许能够有更好的效果。
（2）作业难度梯度的调整
在我实际编写代码的过程中，我认为第四单元第一次作业的难度设置较为不合理。包括继承关系的处理以及对于每个元素中所包含的信息的归类在是实现上存在较大的难度。相比之下，第二次作业的难度反而都集中在类图基本规则的处理上，相较于第一次作业反而显得并不太难。所以我希望在后续的课程开展中做好难度的调控，比如像将第一次作业里继承关系的考察放到第二次作业中或许难度层次会更好一些。
（3）hack组的调整
在我们的互测环节中，hack机制并不会惩罚多次hack同质错误的“狼人”，但在实际修复过程中部分不小心点击“非合并修复”的同学就会吃亏。所以在我的观点里，能否在现有的房间分配基础上建立一个类似“信誉积分”的榜单，将那些“狼人”尽量同时集中在一个房间里，这样也能增加一些“狼人”多次hack同一错误的代价，尽量让我们在互测过程中能对准某个具体错误hack，而不是盲目去碰运气。
来源：oschina
链接：https://my.oschina.net/u/4300980/blog/4165311