oo第四次博客

uml

 

1.两次作业的架构设计

第二次作业包含了第一次作业，我采取的是直接继承。

第二次作业架构：

 

 

 

 

 

 复杂度：

 

 

 

 

大概来说，就是分了三个图：类图、顺序图、状态图，每个图的类关联了它所需要用的图的元素。此外将其中的一些元素重写一些方法和属性，比如myclass存了它的op的引用，myop存了parameter的引用（用于快速处理相关的查询和检查命令），不过这个我没有采用直接继承的方式而是新建了一个类，把类中的一个属性设为了这个元素。
然后把每个需要检索的元素建立了一个List类（其实可以写一个MyList，里面用泛型，然后每个元素直接用这个list，但是因为第一次我只检索了class所以直接写的，没有用泛型，后面我也就懒得改了），在里面处理了，id查询、name查询、重名、不存在等等。
顶层是generalinteraction继承了classmodeinteraction，它主要是对元素的预处理（转型等）、检查规范、处理查询、以及所有元素的访问。最后一个功能的意思是，我在每个类中只存放了与它关联的元素的引用，而对所有元素的查询和修改都是通过顶层的myelelist这个public static final的窗口实现的。
最后还有一个check类，它里面主要是实现三个规则检查，以及相应的算法。

然后复杂度主要是check的时候两个递归加上floyd（之前还曾有过dfs）造成那块复杂度有些高，其他都还好

2.架构设计和oo方法理解
　　一开始完全不知道oo是什么，直观感觉就是把原来的函数变成了方法。经过第一单元的训练之后，我觉得我只是开始用oo方式解决问题了，而且感觉如果不用oo的话，面向过程可能会让我不利于维护，并且甚至觉得oo比面向过程处理问题起来更简单（脚本那种轻量级的除外），第一张对于我来说就是认识oo知道它的作用（以及java程序语言设计、评测机对拍器设计的课程），从多线程一章开始，我开始注意降低耦合度、并且从多线程开始后面的三个单元每次只需要新增或者修改少量的文件即可实现功能扩展（当然后两个单元是功能的线性增加性很大程度上避免了重构，但第二个单元确实真的用科学的手段（复杂度统计）把代码的复杂度降了下来，对后面两次作业的扩展和维护有很大帮助）
除此以外，多线程也是让我学会了新的编程方式对编程能力有很大提高，jml、uml也是让我了解了各种科学的表达方式，学会了很多知识点。
　　最终现在我能运用各种模式，也还算能满足solid，虽然还是和***\***\***等巨佬的代码比起来，还是相对屎山，但至少个人的进步也是很大的。

3.测试
　　第一次作业我还不懂什么叫做对拍。。。
　　从第二次作业开始走上了对拍的道路。。。
　　一开始还会构造边界、压力数据，以及一些诡异的构造，后来就是对拍对拍再对拍了。。。基本上bug都是几十万个饱和数据点可以拍出来的。当然惭愧的是从第三单元开始我就没自己写过对拍器了Orz，写对拍器的心得体会就是其实也有很大的效率问题，不是数据量大就一定测试强，也不是完全随机就可以的，因为那样会造出海量的智障数据（出bug的话还会产生大量违法数据）。。。所以其实构造对拍器一定程度上也是手动构造用例的过程，只不过在一个脚本中融合了大量的可能性，我们只需要大概掌握这些可能性而不必真的像手动构造那样具体到一组数据上，同时我们还要掌握到数据出现的概率不会大量集中在无脑数据和简单数据，保证数据检查的多样性即可。　
　　互测时的对拍。。。全是同质。。。

4.课程收获
　　首先就是代码能力（我是之前没想到我能一周在一周有os、离散、概统、实验、数模的情况下写1000行代码还能de完bug的）
构造数据能力Orz一开始时互测逼的，后来就是保命逼的了。。。
当然最主要的还是oo本身，大屎山变成小屎山了。。。（距离大佬们没法比，但跟自己还是有明显进步的）

5.建议
　　作业有时候会出现一些迷惑行为，虽然最后基本上不影响评测但是让人写不下去。。。
　　课上实验错开一周。。。后面还好，前面刚上完课就做实验，全靠中午才能知道下午要做什么。。。
　　再多放一点优秀代码。

转载于:https://www.cnblogs.com/hhh2019/p/11078616.html