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
-
删掉性能分，更改为子任务 / 部分分的机制，一个随便口胡的方案如下：
第一单元第三次作业可以设置为如下形式：\(30\%\) 的测试点和这个学期的相同，但没有
WRONG FORMAT!，\(30\%\) 的测试点有WRONG FORMAT!，\(20\%\) 的测试点需要支持除法求导，最后 \(20\%\) 的测试点需要支持多元求偏导。如果不删建议扩大测试样例数，
不过根据室友理论课老师的说法是评测机资源不够。原因在 第二单元总结-总结与收获 中有详细叙述。
顺便再补充一个有这种问题的环节，OS 页面置换竞速，指导书说了要换数据，结果最后没换数据，面向数据编程，我的超人！
-
互测中数据范围最好能和公测一样，同时限制每个人针对房内每个角色提交的样例数 (这是为了减少后面进行额外测试的测试点数量)，对于 A 组所有 hack 成功的样例，互测结束后对所有人进行 System Testing，这样就可以很好弥补强测强度有限但有些 bug 因互测房间分配的随机性而测不出来的的问题。
-
目前实验课设置的意义不知道在哪里，管理松散，除仅有的一次外结束后连参考答案也不给出。其中有几次训练其实可以当作一个新单元的预习作业，不如放到训练里面，并给出答案，或是通过一定的手段为其配置评测系统。
不如将实验课改为对上一周的作业进行限时增量开发，临时改变需求，让同学们切实体会一下面向对象的好处。
-
后两个单元实在太水了，没有必要占这么长时间，如果是故意安排成这样那确实没什么问题，如果不是最好可以压缩一下，把时间分给前两个单元，例如前两个单元各一个半月。
-
第四单元整体题面描述实在是太模糊了，最后一次作业讨论区甚至开到了第三页，很多东西完全可以在题面中严谨描述，没必要放到讨论区。如果说这么做是故意的，那我认为这没有任何意义，这只会让我们度过一个又一个迷惑的周末，想到一个又一个 corner cases，而不会让我们更好地学会 UML。
-
最后这条单纯算碎碎念，如果觉得有所冒犯我可以删掉。
虽说助教在水群的发言仅代表其个人，但是我还是希望类似下面这种话可以少一些，尤其是在学期初刚开课的时候，如果一门课的助教这么说话，那我想你对这门课的印象一定不会太好 😅。
不过，一个学期下来，我看到的是全体助教老师为这门课不辞艰辛地付出，为同学们答疑解惑，以及最后精心准备的颁奖典礼，让我明白上面类似的话只是一句戏言罢了。很感谢全体助教和老师为我们带来一门华丽有趣的 OO 课程，让我们在有良好体验的同时也学到了许多干货，度过了一个难忘的大二下学期。
-
UPDATE：建议 1、2、4、5 包含在面试助教的申请中，课程组看了后直接拒绝了面试请求，这让我怀疑「改进意见」这部分存在的意义，抱着改进课程的心态提了一些建议反而因此被拒，只能说祝 OO 越来越好吧。
