BUAA_OO_第四单元总结

OO第四单元总结

摘要

• Homework9、10、11：本次作业最终需要实现一个UML扩展类图解析器，使得可以支持对UML状态图和顺序图的分析，可以通过输入相应的指令来进行相关查询。

前言

作为OO收官的单元，第四单元的含金量并不让人失望。在让我深度了解UML图的同时，也给我机会重温一二单元的设计思想，优化算法细节。虽然相比第三单元的信手拈来，第四单元的完成过程稍微曲折一些，但收获很多，也算给OO暂时画上了圆满的句号。

本单元架构设计

第一次作业

根据UML图的依赖层次，读取时将类元素分成三层，通过三次遍历分层读取：

• 第一层：Class, Interface

• 第二层：Attribute, Operation, Association, Generalization, InterfaceRealization

• 第三层：Parameter

设计后，除了MyUmlInteraction自己实现了MyClass， MyInterface，MyOperation四个类，便于进行后续存储和解析。

UML图

本次作业，类实现的全部接口这种查询，主要是递归，并且多次使用了HashSet，类的顶级父类则是dfs的简单使用，类的操作的参数类型写起来稍微有点繁琐，也有一点小坑（返回值多了void和null），总体来说理清了UML的结构就不算困难。

第二次作业

虽然时序图和状态图多出了许多元素，但是在理解其结构和作业需求后，发现我们仅需要解析部分就可以完成本次作业。如果有后续新增需求，在读取处增加存储就可以了，可拓展性也不错。

这次的图同样可以依托在第一次的基础上，分为三层完成读取。

• 第一层：Interaction, StateMachine, Region

• 第二层：Lifeline, State

• 第三层：Message, Transition

UML图

本次作业理清结构，决定好存储层次后，按部就班完成即可，不涉及复杂的算法，但是需要细心，很多地方容易出小错误。

第三次作业

第三次作业新增了模型有效性检查。

我新增了MyUmlStandardPreCheck类，传入Elements进行预检查，其余结构未变，故不再放UML图。

感觉这就是一次写dfs的作业

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

第一单元

第一单元的第一次作业是自己写得比较舒服的，从设计到实现到最后的结果，每一步都能够让自己满意，觉得有那么一点点面向对象的意思了（估计主要是因为第一次作业简单吧hhhhhh）。到后来第二次就来了表达式嵌套，难度倍增，所以自己还是将主要工作量放在了设计上，前前后后想了一共得有一天吧，最后和胡明博同学一块儿讨论了一个小时，敲定架构，那个瞬间真的有种"Eureka!"的快感。也是从那次开始，我逐渐理解设计的重要性，如果设计科学，那写码就只是一个短平快的过程。

表达式求导这个模块，作为OO入门还是挺合适的。我觉得思考并比较表达式、项、因子等各个元素的异同，进行模块化的设计，对纠正入门者的思想这块儿，虽然痛苦，但帮助很大。简而言之，我觉得第一单元让我对OO产生的理解是求同存异。

第二单元

电梯单元非常考验架构的设计，采用什么模式，调度器有多少职能，电梯有多少职能，乘客的能动性，每一处都要调节到最适合自己架构的微妙平衡点。我从最初敲定的架构就是生产者-消费者模式，其余则是完全剥削乘客的能动性，调度器只拥有分配的权力，其余全部交由电梯处理。这样的优点就是三次作业中，电梯类是完全不需要动的，需要改变的只是调度器。

当然了，这单元强调的还有多线程。线程安全永远要放在第一位，这也是这单元最折磨的地方。

各司其职，这是我第二单元的收获。

第三单元

第三单元的设计基本上课程组已经做完了，但是需要大量考虑效率的问题。所以我在第三单元也就没有多考虑架构问题，写就完事了，也重温了一些算法。

本单元给我的体会就是，OO毕竟是一种思想，没有基本的对算法和数据结构的掌握，再优秀的架构设计也没有办法帮助你完美地完成一次任务。

第四单元

第四单元让我对“对象”的理解更加丰富了，某一具体功能是一个对象，所有有相似特征的元素是对象。设计时，需要分解需求，设计对应的模块化的方法，同时分析问题的主体，分门别类。配合UML这样一个本身强调层次的对象，对我们理解的深入帮助很大。

测试理解与实践的演进

我采用的测试方法比较简单直接。

• 手搓极限数据或特殊数据

• 黑箱测试+对拍

这两种方法最为高效。前两单元，就是简单的手搓数据了。第一单元自己疏于测试，导致了第二次和第三次作业的低级错误频出。第二单元则是因为多线程的原因，测试难度较高。

后面则是较多地使用了数据轰炸来黑箱测试。这样找bug确实高效，易于发现自己忽视的问题。

当然了，最重要的还是书写代码的时候就理清思路，步步为营。总指望亡羊补牢，那终究是有些晚了。

课程收获

OO是我这学期最有收获的课了！体系的完备、作业的递进，都让我感觉到了课程组的付出。

论及收获，首先自然是思想上的提升。面向对象、面向过程，都有其存在的价值，两种思想，都是我们要一直牢记，努力参透的。同时，关于设计、关于迭代、关于测试，OO都为我带来了前所未有的新认识。除了第一单元出现了重构外，剩余的三个单元都是迭代设计完成的。

其次，就是对编码能力的提升了。通过OO，我开始接触java这种相比较C语言更为高效的语言。从预习作业的一知半解，到最后的层层深入，这可以算是OO的馈赠吧！一周（其实是两天）撸出千行代码，在有了OO之后，也不算啥事了。除此之外，相关工具的使用也更加熟练了，git，markdown，都算是熟悉了。

最后，则是让我感受到了分享的温暖。除去大佬云集的讨论区，身边的刘俊一、刘博一、胡明博、曾畅等同学在整个学习过程中热情的讨论和分享，也帮我扫清了许多困难，让我在繁重的课业下，感受到有人同行的坦然。

改进建议

• 预习作业整体的结构是合理的，从结果来看也非常高效。但是其中指导的部分可以适当增加，毕竟大部分同学都是从零开始，那种跟后期作业风格一致的预习作业指导书有的时候确实有点谜语。

• 作业的更新换代是否可以慢一些？真正经典的东西并不需要时刻变化。当然了，同样难度，考察不同方向，确实是可行的思路，但是大致看了一下感觉今年的难度已经比前年大了许多，虽然提高能力是时代的要求，但这种难度上的提升需要更多的斟酌。

• 训练部分的存在感实在是太低了...

• 感觉预习作业把好多理论课的事都做了让理论课反而可有可无了？理论课需要一些亮点，不然真的很难让人有收获。

写完这篇博客，大二下最后一个任务也就完成了。感谢OO，给我乏善可陈的大二下添上了鲜亮的一笔。