面向对象程序设计 第三单元总结

　   第三单元总算是轻松一点了

(1)总结分析自己实现规格所采取的设计策略

　　在这三次作业中，我在实现规格时采用的设计策略是这样的：在实现顺序方面，我先实现相对于整体代码比较独立的异常类（经典写完两个就等于写完所有），在实现层次比较低的数据类，如person类，group类等，最后再实现功能繁杂，方法多多的network类。在实现方法方面，我会先整体浏览一遍所有方法，梳理方法的调用关系，大概有一个层次。之后再按这个层次依次实现方法规格。在实现时，我会仔细阅读方法规格，明确前置条件与后置条件，确定方法的功能与目的，并采用恰当的数据结构与算法实现。

(2)结合课程内容，整理基于JML规格来设计测试的方法和策略

　　在这三次作业中，我都采取了模块化的测试方法，辅以junit测试。我将每个方法都在debug中测试了一遍，在输入满足前置条件的数据，进行单步调试的同时，追踪规格中明确要求的后置条件，并与规格中的要求相比较，以此确定方法的正确性。如果某个方法错误，那就再测试该方法调用的其他方法，以此确定bug位置。由于这三次作业的程序，许多的功能都相对独立，所以只要保证每个功能模块没有问题，就可以确定整体的程序没有问题。除此之外，在最后一次作业，我也用junit测试了一些比较复杂的类，找出了一些错误。

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

　　容器的选择与使用一定要契合数据的特征，而不是图哪个省事就用哪个，这样反而会使数据结构变得复杂。如network类的emojiheatlist，很显然就具有键值对的特点，应用hashmap。再如异常类中的具体id触发异常计数，为保证不出现重复计数，并且便于查询，也应该使用hashmap。类似的还有person类中的acquainment和value。而其他的数组，就都可以采用arraylist，有些应使用hashset避免重复的数组，如network类的people，由于规格要求实现contains方法判断是否已有相同id对象，所以也可以用arraylist实现，避免麻烦。

(4)针对本单元容易出现的性能问题，总结分析原因 如果自己作业没有出现，分析自己的设计为何可以避免

　　在本单元中，我的作业出现的性能问题，主要是在iscircle方法中。我为省时间，采用了递归的实现方法，导致在强测中出现爆栈。最后我用dijkstra方法重新实现了这个方法，优化了作业性能。

(5)梳理自己的作业架构设计，特别是图模型构建与维护策略

　　在这三次作业中，架构设计基本已经被规格限定得差不多了，我的作业中的继承与接口也都是按照规格所要求的写的，并通过接口实现规格中的方法。

　　对图模型的构建，我采用的是比较简单的二维数组的形式，person作为节点，value作为边的权重。为维护图，我没有将图单独作为一个变量随时更新，而是在调用sendindirectmessage方法后，再根据现有的person与value计算图。这样就省去了在改动person数组时，要对图所作的更新。