OO第三单元总结：和JML死磕的那些日子

杨二郎ZC061030 2026-05-28 09:52:47

前言

说实话，第三单元刚开始的时候我是有点懵的。前两个单元我已经慢慢适应了面向对象的思维，结果Unit3直接给我扔来一堆@requires、@ensures、@signals，整个人都不好了。不过回过头来看，这一单元确实让我对"设计先行"有了完全不同的感受。

另外我个人原因第十次作业没有提交，所以这篇博客主要聊第九次和第十一次作业，以及研讨课上那个"击鼓传花"游戏。

一、我理解的JML和规格驱动开发

JML是什么感觉

刚看到JML的时候，我第一反应是：这不就是注释吗？写这个有什么用？

后来才慢慢明白，JML不是普通注释，它是可以被工具验证的契约。一个方法的@ensures子句，严格规定了这个方法成功执行后，世界是什么样子的；@signals子句规定了什么情况下抛什么异常。它的精髓在于：你写代码是在实现这份契约，而不是在凭感觉猜测业务逻辑。

举个我踩过的坑：likeVideo这个方法，我最初想当然地认为"点赞就是+1"，结果JML里写的是toggle。如果我一开始认真读规格，就不会在这里栽跟头。规格就是说明书，不看说明书就动手，是我前几次的通病。

还有一个让我印象很深的细节：getInterest计算公式里有个(totalVideos - watchedVideos.size() + 1)，那个+1是JML明确写出来的。这种细节如果靠"猜"，十次有九次猜错。

规格驱动开发的实际体验

我现在的习惯是：先把所有@signals子句列出来，确认异常的触发条件和抛出顺序，再看@ensures后置条件，最后再动手写代码。@signals和@ensures不是并列关系，而是分支关系，这一点很重要。

二、JUnit测试经验总结

写测试的"正确姿势"

最开始我想：直接构建一个场景，调用一下，看返回值对不对，不就行了？

后来发现这样写的测试其实很脆弱，因为它只验证了"答案对不对"，没有验证"副作用有没有"。对于标注了pure（纯查询）的方法，调用前后网络状态不能有任何改变，这才是最容易被实现者忽略的地方。

所以我的测试里加入了镜像网络对比：调用前建一个状态完全相同的镜像网络，调用后用strictEquals逐一对比每个用户的状态。

这里有个坑：我最开始想直接调network.getVideos()来对比视频状态，但评测机的Network类里没有这个方法（因为它不在官方接口里），编译直接报错。最后改成用UserInterface.getInfluence(type)来间接感知视频状态的变化——因为influence等于用户上传视频的heat总和，如果视频状态变了，influence也会变。

几个测试心得

测试异常路径，而不只是正常路径。recommendNthUp有四种异常，每一种都要单独测。
边界值是重点：rank=0、rank负数、候选人数量刚好等于rank、比rank少1……
不要写"太聪明"的测试。测试依赖隐含假设（比如特定的totalVideos值）时，场景稍微一变就崩了。

三、三次作业的迭代过程

容器选择在迭代中的重要性

第九次作业到第十一次作业，方法数量几乎翻了一倍。最直接的感受是：容器的选择在迭代中变得非常重要。

比如receivedVideos（用户收到的视频列表），最初用ArrayList，每次往前插入（prepend）都是O(N)。到hw11新增了大量的uploadVideo和forwardVideo操作，换成了LinkedList，addFirst()变成O(1)。

还有following集合，ArrayList的isFollowing()每次要遍历是O(N)，换成LinkedHashSet后查询O(1)，还保留了插入顺序。

如何发现性能瓶颈

主要靠三个方法：

看算法复杂度：queryMutualFollowingSum如果每次查询都双重遍历用户，是O(N²)。改成在followUser/unfollowUser时维护动态计数器，查询变O(1)。
看调用频次：queryLongestDecSeq是图上的DFS，加了备忘录（memoization）之后每个节点只算一次。
看排序里的重复计算：recommendNthUp排序时先把所有候选人的分数缓存到HashMap，避免比较器里重复调用computeUpScore。