OO第三单元作业总结

OO第三单元总结

实现规格时的设计策略

这一单元主要学习的内容是掌握JML，一方面需要通过JML来完成代码实现，另一方面则是通过读JML了解写JML的方式，在以后写代码时也需要为他人书写规格。

由于有JML的指导，所以我能比较独立的完成各个方法的书写。但为了了解本题的方法的意义和更快地理解代码，看一遍题目背景是我的第一步，这样面对方法名，则可“望文生义”。第二步，是将所有方法的JML都浏览一遍，以此来确认存储变量的类型，只看单个方法的JML，很容易认为需要用Arraylist来实现方法，甚至是多个Arraylist来实现，但事实上，往往使用Hashmap能更好的实现，也更贴近本单元查询次数多的情况。第三步，则是具体方法的实现，我首先处理的是异常的情况，再处理正常情况。如果实现非常通俗易懂，则按JML根据设计的变量类型翻译即可，如不是，则可设计效率较高的算法来实现，为了提高代码的可读性，我也设计了额外的方法，方便多次调用。

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

主要是需要检查自己的代码是否满足JML的约束。

1.通过Junit进行单元测试

2.仔细阅读代码的逻辑，由于JML往往长，括号多，很容易误读，所以对于复杂的方法，进行一个二次检查也是很必要的。但这样的效率实在是非常低。

3.写一个对拍机。只要样本够多，应该也许maybe可以发现问题。

总结分析容器选择和使用的经验

在读单个方法的JML时，很容易选择Arraylist，但是，只要在写代码之前大致读以下所有的JML，就可以发现，本单元经常需要查询。因此，选择Hashmap是更好的选择，因为对于本单元中的对象，几乎都有特殊的独一无二的id作为可作为key。

经验:在写具体实现前，对所有需要实现的代码都有个大致的了解是一个比较好的选择。观察这些方法在查询数据的方式和所需要的值，观察这些值与什么能有着单一而紧密的联系，然后再来选择容器。这也提醒了我们在以后写代码时，将所有方法名都写好，在开始写具体的方法会更好地避免容器选择不能满足现有需求的问题。

本单元出现的性能问题

1.第一次作业

第一次作业出现性能问题的方法是isCircle()，由于本单元主要与图论相关，因次当我看到该方法需要查询两个点之前是否关联时，第一反应是写一个深搜。然后果不其然，强测中有两个点CTLE了，于是我查询了并查集的写法，进行了优化。

第二次作业

第一次作业出现性能问题的方法是qgam,qgav,如果每次qgav都调用qgam，就容易导致多次重复计算，时间超出。因此不妨在每次Group加入或者删除人的时候，就存储目前关系的平均值，在每次qgav,qgam时都可直接得到想要的值。

第三次作业

第一次作业出现性能问题的方法是最小路径的计算，基础的dijkstra的算法无法过强测，需要进行一波堆优化。

作业架构设计

看到这图觉得自己的架构好像可以再优化下……

本单元主要根据了JML来确定自己的架构，主要是一波继承。

本单元主要最后得到的应该就是一张图。整体上就是根据JML来写，没有什么创新点。

总结与收获

还记得rwg老师在课上说的：“JML语言还存在一些问题，我们这个单元的主要目的不是让你们学会JML语言，而是加深你们对规格的理解，在之后写代码的时候，要在脑海中有这种规格的意识，能把自己的逻辑用规格描述出来，这个单元就算掌握了”（复述的不太准确，但大致是这个意思）。我觉得说的十分有道理，这也算是我这个单元最大的收获，希望以后的代码也能和这次一样能看吧。