OO第三单元总结

Posted 2021-06-01 xxqwbjfy

一、实现规格所采取的设计策略

　　首先大致读一遍规格，粗略了解整个系统的架构：Network管理基础类Person和Group以及Message。然后先实现这三个基础类，再根据Network规格实现MyNetwork并适当修改基础类的结构。

二、基于JML规格来设计测试的方法和策略

　　对于pure方法，基本不需要对其加以测试；

　　对于不抛出异常的方法，针对规格的不同require语句分类设计几组测试数据；

　　对于抛出异常的方法，再上述基础上再将不同异常触发条件进行组合，看异常抛出顺序是否满足要求。

三、分析容器选择和使用的经验

　　所有容器都不能装入原始类型，必须将其包装成对象才可装入。

• Arraylist：实质上就是一个包装后的数组。使用简单。可以方便地根据偏移量直接得到所需对象，但只适合对尾部对象的增删。
• HashMap：在两个对象间建立键到值的映射关系。由于使用了hash，在查找上比较方便。
• Linkedlist：包装起来的链表。适合主要对头尾进行操作的使用场景。数据的插入和删除比较方便。

四、性能分析

• qci：直接在Network中实现查找的话每次都需遍历完该person所在的连通图，复杂度为O(n)，n为person所在连通图的大小。似乎复杂度尚可接受，但一旦与qbs组合起来就会达到O(n^2)。
• qbs：如上所述。解决方法是给每个连通图中的节点都分配一个相同的blockId，在添加关系时如果两个person的blockId不同则将其中一方的所有blockId都改为与对方一致。此举使ar复杂度达到O(n)，可以接受。同时在Network中管理一个block计数器，每次ap时计数器加一，ar时根据双方blockId是否相同决定block计数器是否减1。这个改进直接使这两个指令复杂度降到O(1)。
• qsv/qgam/qgav：设置有效标志位。在更改数据后对其标志位清0。若标志位有效则可直接返回储存起来的结果。

五、架构设计

架构基本不需设计。

Network:

• 加入了blockCount对block计数。

Person:

• 加入了blockId标志所处的连通图。
• 由于第一次作业时不会使用Map，因此定义了一个愚蠢的类来储存每个aquantaince对应的value。由于其不太影响性能，在后续的作业中没有用Map重构。

六、心得体会

感觉提前过起了码农的生活（bushi）。

实际的工作中应该每写一个方法就对其进行测试，否则就会在debug时面对一长串代码无从下手。但为了节省时间，我基本上没有进行测试。结过导致第三次作业一些不符合规格要求的代码迟迟无法发现。

JML规格比原代码都长，估计没什么实际应用价值吧。