OO第四单元与课程总结

一、本单元作业的架构设计

本单元三次作业的架构大同小异，而第一次作业内容最少，UML图最清晰，所以只放了第一次作业的UML图。

本单元作业的设计重点就是设计储存UML元素的数据结构。我使用了以下集合来描述一个UML图，以便于实现各种查询工作（见上图红框部分）：

• elementMap : 是一个储存<元素ID， 元素>键值对的HashMap，用于根据元素ID获取对应元素对象。
• elementList : 是一个储存所有元素的ArrayList，主要用于遍历所有元素的时候使用。
• elementInfoMap : 我设计了一个ElementInfo类专门用来储存一些复杂一点的信息，主要储存以这个元素为parent的元素数组和这个元素的父类或父接口（如果这个元素是类或接口），作用是根据一个元素快速找到它所有的children和它的父类。MyUmlInteraction里elementInfoMap就是用来储存<元素ID,元素对应ElementInfo对象>的HashMap。

以上集合都会在MyUmlInteraction的构造函数中进行初始化，之后所有的查询方法都不会改变它们的值。

我的一个设计思想就是在查询内部处理中全部使用id来唯一表示一个元素，这样可以避免很多复杂的类型判断。只有在需要获取元素对象的详细信息的时候才会通过id来获取对应的对象（比如要求返回元素名字，判断元素类型，或者第三次作业中直接返回元素组成的集合等等）

在有了elementInfoMap之后，查询类的属性，父类，实现的接口等都可以完全用图dfs和bfs来解决，而不需要遍历所有元素。

以上数据结构在第二三次作业中基本没有改动（第二次作业中为了方便状态图查找次态在ElementInfo中添加了次态集合这一属性），只是添加了很多方法。为了保持单个文件500行的限制，我创建了几个工具类，把接口中的方法封装了起来，然后在MyUmlInteraction里直接进行调用，这也使得第二三次作业的UML稍显复杂，但是本质上和上面的UML图没有区别。

二、在四个单元中架构设计及OO方法理解的演进

在架构设计方面，我在第一单元的时候架构设计明显经验不足，第二次作业进行了大量改动，第三次的作业时直接又对自己的代码进行了重构。第一单元的架构实际上是比较混乱的面向过程的思想居多，对面向对象的运用也多半都是暴力封装一些方法，没有用到多少面向对象的特性。

第二单元经验丰富了一些，也更加注重架构的合理设计。第二单元的第一次作业中，我花了较长的时间去设计一个合适的、可拓展性高的架构。之后第二、三次作业中也只是在第一次单元的基础上添加了一些额外功能，核心功能仍然可以沿用第一次的设计。

第三单元重点在于算法的设计，在这个单元我复习了一些数据结构中学到的算法知识，也自学了一些新的算法。算法学会了，但是在在强测中还是因为细节问题丢了分。在这一单元虽然没有架构压力，但是也让我意识到用面向对象思想来实现算法，和用C语言实现算法存在着很大的区别。虽然java里各种集合可以很方便地进行遍历，查找工作，但是同样很容易在细节处出现问题。

第四单元的重点在于理解UML中各种关系，在这基础上要实现很多查询方法，对数据结构的设计有较高的要求。开始设计之前首先要对UML中各种元素的关系有一定的了解，之后才能实现一个UML图的解析工具。

在四个单元12次编程作业中，我对面向对象的理解逐渐深入，设计经验也逐渐丰富。从一开始只知道暴力封装到如今渐渐理解了为什么面向对象要有那么多从C语言角度看起来怪怪的特性。在作业的实践过程中，我也学到了很多设计模式，如工厂模式和生产者消费者模式。这些都是非常经典，也非常好用的设计模式，它们的设计思想可以应用到很多很多的领域中去。一次次架构的设计让我的工程能力也得到了一定的锻炼。一开始的我还在为一个求导程序设计方案熬上很晚的夜，渐渐地在这种工作量稍大的程序面前有了底气，也有能力更快的设计出一个合理的架构。

三、四个单元测试理解与实践演进

经历了上学期的计组设计，我很深刻的认识到只靠读代码找bug的局限性。不真正的跑一下自己的代码，永远也不会知道它会在什么奇奇怪怪的地方造反。我觉得从第一单元开始，课程组就在引导我们自行编写测试程序，对自己的程序进行黑箱测试。我在第一次作业中就开始用python和命令行工具，编写黑箱测试代码。我最初编写黑箱测试代码的原因很简单，就是因为我看到我们输入的表达式完全符合python格式，指导书中还详细阐述了正确性的判断标准，所以我马上就想到了把测试数据扔给python去计算然后比对结果来进行自动化测试。通过与同学们的交流，我在之后的几次作业中逐渐完善我的评测机设计，现在已经能比较熟练的实现数据随机生成与结果比对功能了。

第二单元的自动化测试需要计时，我没有去了解相关的内容，因此也没进行黑箱测试。但是借助一些python画图功能，把单调的输出信息变成一个动态的图表，这样可以更好的查看电梯运行的轨迹，从中也更容易发现电梯运行方式与自己设计思路不符的地方，优化了我的debug体验。

第三、四单元由于编写评测机逻辑很复杂，相当于重新实现一遍作业，所以主要测试方式就是和朋友的程序对拍，通过结果比对发现问题。

四、课程收获

最明显的一点就是编程能力的提升。这门课的主要时间都是在写编程作业，12次编程作业的设计与反思让我得到了很多编程练习。在一次次debug中我得到了成长，强测中的WA和互测中来自同学的无情轰炸让我认识到了自我测试的重要性，拖延之后熬夜设计作业架构让我认识到了时间管理的重要性。

总的来说，OO是一门很锻炼人的课程。经历了这学期的OO，我在面对软件设计的时候明显会更有底气。在OO中我学到了很多精彩的设计思想，这些设计思想不仅仅局限于java的设计，甚至也可能不仅仅局限于程序的设计，可以应用到许许多多的领域中去，我想这是我在OO结束之后最大的收获。

五、三个改进建议

• 我认为JML指导书中对@requires关键字的阐述和课程组实际要求不一样，不同点在于不满足@requires条件时程序的行为规范。（这个讨论帖中有相关问题的讨论）课程组在对应作业的讨论区以解答的方式做了说明（我认为这个说明和指导书的内容相矛盾），但是我建议应该在指导书中对相关情况进行说明。因为如果不是在置顶帖或指导书中说明的话，大多数同学可能会遗漏掉这个帖子的信息。针对上面@requires的问题我与很多同学进行了讨论，大家都认为课程组并没有说明白这种情况的处理方式（大家都没看到助教在讨论区提问下的解答）。
• 我建议作业难度可以随时间递增。我觉得第一、二单元的作业的难度明显高于第三、四单元的作业，导致在第三、四单元突然轻松之后同学们可能不愿意再花心思认真设计，认真测试了。
• JML相关工具使用起来非常不方便，而且也没有起到测试工具应有的效果，体验就是浪费了一些时间但是没有任何收获。

六、线上OO课的体会

线上授课对于OO来说，硬核的部分没有收到多大影响。但是在家完成作业，对于时间管理和自控力的要求就比较高了，很容易出现在家中过于放松不想学习导致作业完不成的情况。而且在家里独自一人完成作业，不能方便的和同学交流想法，也一定程度上影响了我们的学习效果。我认为，还是线下授课的方式收获更多。