2021-面向对象设计与构造-第四单元总结

第十三次作业#

UML 类图#

架构与实现#

感谢课程组送了个标程，我参考了这个标程的架构进行设计，去除了一些没有意义的部分，例如接口中只存放它的父亲接口，因为其它东西也不会查，存了也是白存。

对于判断两个方法的参数所组成的多重集是否相等，我使用了 HashMap 进行比较，键和值分别为对应参数类型和出现次数。

测试与 bug 分析#

但是，标程都送到手里了，我还是能写挂。只能说，我是脑瘫。

可能是上个单元暴力写惯了，获取一个接口所有祖先接口这个方法，我直接暴力，没有记忆化，然后就寄了，被一个构造的点直接卡 T。

这周因为去西安邀请赛捡漏，还要复习 OS，没时间写评测机，就随手构造了几组样例进行测试。不过只有想到这一点去构造才能发现这个问题，要怪就怪我思维僵化，没好好读标程，爬了。

第十四次作业#

UML 类图#

架构与实现#

状态图中，UmlState / UmlPseudoState / UmlFinalState 是点，UmlTransition 是有向边，UmlEvent 是边的附加属性，然后就是一个简单图论问题。

顺序图中，UmlLifeline 是点，UmlMessage 是有向边，然后就又是一个简单图论问题。

测试与 bug 分析#

因为要考组合数学，所以也没时间写评测机，只针对一些问题构造了样例，最终没有出现 bug。

第十五次作业#

UML 类图#

架构与实现#

在上一次的基础上进行一些检测，主要说一下图论部分的实现。

找环其实可以拓扑排序总共 $O(n)$ 做，我懒得写直接单次 $O(n)$ 判从每个点出发能否回到自己。

找是否重复继承只需看每个点是否只会被访问到一次即可，这样做单次是 $O(n)$ 的。

测试与 bug 分析#

既然前两次没写评测机，那这次当然也不写了（逃

构造性地测了几组样例就去 cf 掉分了（溜

最终没有出现 bug。

总结与收获#

架构与 OO 思想#

总结自己在四个单元中架构设计及 OO 方法理解的演进。

第一单元让我学会了将每个元素尽可能地细分为多个对象，体会到了层次化设计的好处，并在重构中意识到架构才是一切的基础。

第二单元让我学会了多线程设计中基础知识，包括锁、并发错误、生产者-消费者模式等，最后的架构也是一个以生产者-消费者模式为基础的集中式调度系统。

然而，这两个单元架构最终的服务对象是更快更正确地获取更多的性能分，必然在一定程度上牺牲了拓展性。不过，没有哪个架构是一定正确的，再合适的架构也抵不过离谱的需求让你的架构被迫重构。

第三单元架构已经规定好了，主要还是 JML 的学习。

第四单元架构虽然看似没有规定好，但其实已经八九不离十了，而且复杂度相比前两个单元也简单很多，并没有特别深的体会，重点其实是对 UML 中细节的理解。

测试#

总结自己在四个单元中测试理解与实践的演进。

第一单元使用 python 写的 sympy + xeger + subprocess 评测机进行暴力对拍。

第二单元分别使用了简易版 C++ 离线评测机和实时 Java 评测机进行评测。

第三单元使用 C++ 的 generator，之后和室友进行对拍，hack 时构造了一些边界样例。

第四单元，数据的生成较为繁琐，鉴于时间原因，选择手动构造样例进行测试。

总的来说，测试有两种方式：

• 使用大量随机生成数据，这种方式不用动脑子，可以测出很弱智的 bug，相当于弱测。
• 手动构造特殊样例，这种方式需要动脑子，可以去检验一些 corner cases。

当然也可能是上述两种方式的结合，即使用带有一定构造性质的算法进行随机生成数据。

对于数据集较小的问题，通过随机和爆搜就可以覆盖到绝大部分情况 (例如计组)。

对于数据集较大的问题，仅靠单一随机算法生成的数据覆盖面不够广，如果你愿意投入时间，那么可以去手动构造多种随机算法以及特殊样例。否则，只能提高代码质量，努力从源头上杜绝 bug，相信自己玛丽。

课程收获#

总结自己的课程收获。

和 OS 一起初步熟悉了 git 的使用。

初步掌握了使用 Java 编写微型工程项目的能力，并对面向对象思想有了一定的理解。

初步点亮了层次化设计模式、正则表达式、多线程设计模式、JML、UML 等科技树。

初步练习了使用 python、Java、C++ 进行代码的测试。

改进意见#

立足于自己的体会给课程提三个具体改进建议。

多提几个应该没问题吧（x

1. 删掉性能分，更改为子任务 / 部分分的机制，一个随便口胡的方案如下：

   第一单元第三次作业可以设置为如下形式：$30\%$ 的测试点和这个学期的相同，但没有 WRONG FORMAT!，$30\%$ 的测试点有 WRONG FORMAT!，$20\%$ 的测试点需要支持除法求导，最后 $20\%$ 的测试点需要支持多元求偏导。

   如果不删建议扩大测试样例数，不过根据室友理论课老师的说法是评测机资源不够。

   原因在 第二单元总结-总结与收获 中有详细叙述。

   顺便再补充一个有这种问题的环节，OS 页面置换竞速，指导书说了要换数据，结果最后没换数据，面向数据编程，我的超人！

2. 互测中数据范围最好能和公测一样，同时限制每个人针对房内每个角色提交的样例数 (这是为了减少后面进行额外测试的测试点数量)，对于 A 组所有 hack 成功的样例，互测结束后对所有人进行 System Testing，这样就可以很好弥补强测强度有限但有些 bug 因互测房间分配的随机性而测不出来的的问题。

3. 目前实验课设置的意义不知道在哪里，管理松散，除仅有的一次外结束后连参考答案也不给出。其中有几次训练其实可以当作一个新单元的预习作业，不如放到训练里面，并给出答案，或是通过一定的手段为其配置评测系统。

   不如将实验课改为对上一周的作业进行限时增量开发，临时改变需求，让同学们切实体会一下面向对象的好处。

4. 后两个单元实在太水了，没有必要占这么长时间，如果是故意安排成这样那确实没什么问题，如果不是最好可以压缩一下，把时间分给前两个单元，例如前两个单元各一个半月。

5. 第四单元整体题面描述实在是太模糊了，最后一次作业讨论区甚至开到了第三页，很多东西完全可以在题面中严谨描述，没必要放到讨论区。如果说这么做是故意的，那我认为这没有任何意义，这只会让我们度过一个又一个迷惑的周末，想到一个又一个 corner cases，而不会让我们更好地学会 UML。

6. 最后这条单纯算碎碎念，如果觉得有所冒犯我可以删掉。

   虽说助教在水群的发言仅代表其个人，但是我还是希望类似下面这种话可以少一些，尤其是在学期初刚开课的时候，如果一门课的助教这么说话，那我想你对这门课的印象一定不会太好 ​😅​。

   

   不过，一个学期下来，我看到的是全体助教老师为这门课不辞艰辛地付出，为同学们答疑解惑，以及最后精心准备的颁奖典礼，让我明白上面类似的话只是一句戏言罢了。很感谢全体助教和老师为我们带来一门华丽有趣的 OO 课程，让我们在有良好体验的同时也学到了许多干货，度过了一个难忘的大二下学期。

7. UPDATE：建议 1、2、4、5 包含在面试助教的申请中，课程组看了后直接拒绝了面试请求，这让我怀疑「改进意见」这部分存在的意义，抱着改进课程的心态提了一些建议反而因此被拒，只能说祝 OO 越来越好吧。