2020 OO 第四单元总结 UML

title: 2020 OO 第四单元总结 date: 2020-06-14 19:10:06 tags: OO categories: 学习

1. 本单元三次作业的架构设计

本单元的代码编写与第三单元有相似之处，课程组已经提供了相应的接口，我们只需要满足具体的实现。在架构设计上我选择了建立MyUmlClass等类，采用适配器模式以管理UML对象，并配置相应的方法的方式，更加符合面向对象的设计思维。

1.1 第一次作业

在第一次作业其实还没有考虑好迭代开发，在UML对象的存储方式上比较混乱，有的采用Arraylist、有的建立了从id到元素的映射map、有的建立了从name到元素的映射map，导致之后第三次作业处理异常输入时花了很多时间重构。做的还可以的是设置了类图单独的管理器，核心类直接调用管理器的相关方法，便于之后两次作业的迭代。

第一次作业没有遇到Bug，感动。

1.2 第二次作业

第二次作业增加了UML状态图和时序图，我分别建立了管理对应图像的管理器类，核心类调用管理器的相关方法。

第二次作业没有遇到Bug，很感动。

1.3 第三次作业

第三次作业增加了多种模型有效性检查，现在想来我对异常输入的处理还不到位，进行了很多重构。

第三次作业没有遇到Bug，感动到差点忍不住流泪。

第三次作业类图如下所示：

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

2.1 第一单元

在第一单元，我通过预习对于Java的基本语法和继承关系有了一定的了解，不过每次写代码时并没有考虑到下一次的迭代，算是次次重构。第三次作业设计的结构有着比较好的扩展性，将因子和因子运算方式抽象为对象，实现了求导接口。如果之后还要增加新需求，对于每一种新函数只要在内部配置求导方法，对于每一种新的运算方式只需要在内部配置运算规则，层次化的表达式存储方式可以通过统一的接口进行因子类型的转换。

在这一单元，我进一步实践了继承、接口等Java的特性，不过代码还是以面向过程为主。

2.2 第二单元

第二单元从第二次作业开始增加了多电梯和对多线程的考察。这一次一开始就希望能为后续的扩展留好迭代空间，电梯设计为有限状态机，三次作业都是采用生产者/消费者模式。其中“生产者”为输入线程，将读取到的请求放到“货架”上；“消费者”则是每个电梯线程，以一种类似观察者模式的方式追踪“货架”的变化。之所以说是类似，是因为我每次都是在电梯自身状态发生改变后获取当前的“货架”内容，而不是“货架”一有更新就通知电梯，我只有“货架”类的方法是上锁的，其他类调用时不需要考虑是否会引发线程不安全问题，写起来很方便。

这一单元的面向对象意识有所提升，不同类协同合作，实现高速载人。

2.3 第三单元

第三单元我觉得在架构设计上课程组给的规格已经给了很多提示，自己也没有太多发挥空间。主要的难点是几个算法的实现。实验课倒是学习了垃圾回收机制，结合讨论区查看了HashMap相关的底层实现，在作业中则表现为进而选择为其设置初始容量。

2.4 第四单元

建立MyUmlClass等类，采用适配器模式以管理UML对象，并配置相应的方法。

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

第一单元是随机数据+讨论区数据对拍，第二单元多线程耗时长，所以用了Pb的多线程评测机；第三单元发生失误，在第二次作业漏测了一条指令，结果正好出错，强测爆炸，之后第三次就老老实实Junit单元测试了；第四次作业以手动构造样例为主。

那么当我们在测试的时候，我们在做什么？最简单来说就是考虑所有输入的结果，并且保证每种都会有正确的交互，结果。但是在实际过程中要完全覆盖所有的可能性显然是做不到的，所以说在测试的时候我们应该尽可能地取出典型样例，而这就是两种方法——随机生成数据或者手动构造针对性数据。

而对于互测来说，要同时检查7个人的错误，单单靠在控制台输入输出显然是低效的，因此也需要结合脚本统一测试。在四次作业我都是使用手动构造数据+评测机对拍测试的方式（嫖来的东西真香），我自己也学习了Python语法，写了对拍程序，接下来打算学习下某位大佬的可视化评测机是咋写的。

4. 课程收获

一定一定要做好测试！写完代码不测试就像晚上开车不开灯
学习了Git的使用、Java/Python的基本语法、多线程、契约式编程、UML等知识
算法无论何时都非常关键，接下来可以继续加强这方面的练习

5. 改进建议

首先是关于实验课，和每次作业都会有非常快速且积极的反馈相比，实验课不公布成绩，只通过后一次课件的ppt展示整体的完成情况，让人不知道自己做的到底对不对，训练效果有所折扣。另外某几次实验课的难度确实有些大，虽然也让我对GC垃圾回收机制等有了一定了解，但那次找Bug真的是灾难……改进上我觉得可以降低实验课所占分数比（虽然我很希望被捞），增加讨论占比，每次结束后与作业一样公布结果。
然后是关于研讨课，看了我好几个同学的博客都在批评研讨课后期太水，我其实觉得R老师的研讨课还是安排得比较好的。其实我感觉按照当前研讨课报名方式，后期研讨课存在灌水现象是非常正常的。OO给我的感觉是一门下线很高,上限无穷无尽的课程，你永远不知道隔壁的大佬为了写评测机和优化算法都用了什么高深的技巧。然而大佬的数量是有极限的，按照两周一次每次3-4个人的频次，自然不可能所有人都拿出“干货”。这一点我觉得R老师后期研讨课会安排同学做作业总结就非常好，说的也是我们我觉得如果把这个当作每次研讨课的保留项目，让所有同学讨论不同架构和各自的优势，也比较方便大家优化自己的代码，避免大佬很快讲完无话可讲的情况。
最后关于作业，我觉得JML可以放在第一章（Pre之后），前两单元对JML工程体系的帮助可能并不大，短期内JML工具链应该还是不完备的，（当然不排除大佬暑假致力于为下一届带来船新的JML体验的可能），所以下一届应该也和我们的体验差不多，将JML可以放在第一章，可以一开始就给大家一个关于契约式编程的粗浅理解，更早地感受到规格化描述和迭代开发的重要性，在多项式和多线程电梯也能少吃一点苦头。

6. 线上学习OO课程的体会

与OS、航概等相比，我觉得本学期OO是收到疫情影响最小的一门课程，本身也没有考试（而是愉快的周周乐），期末受到的影响也不大。而且慕课可以随时回放，研讨课虽然有点冷清但线下也未必更好，所以线上学习OO我感觉很是很愉悦的一门课程。

记得在上OO这门课之前我还上X乎看了往届学长们对课程的评价，看到曾经的吐槽，看到X乎上学长关于OO课程改革的回答，这一学期我也亲身体验了OO，还是不知多少年一遇的线上特供版（笑哭），OO让我有了获得知识的充实感，一次次的训练作业也是循序渐进，助教也很认真负责。感谢orz