总结本单元两次作业的架构设计
第一次作业
首先按照惯例，先上这一次作业的类图：
在设计这一次作业的架构时，我综合考虑了指导书中对功能的需求和提供的jar包里各种element的类提供的方法，发现通过把element进行分类管理之后就能很好的满足大部分查询功能。但是同时我注意到，虽然class类和end、interface、assoend等类在作为element的基础上，是属于同一个层次的，在jar包也都把他们写为了umlelement的子类，但是实际上我认为不管是在uml图的设计过程还是我们写的作业程序的查询过程中，class类对于和它有关系的其他类实际上是从属关系，我们的查询指令也都是以某一个类的名字为单位进行查询，这就让我在设计的过程中，为了数据管理的方便，自己又单独写了一个myclass，它的成员变量分别是和这个类相关的attribute、interface等，同时由于在对需求的整理中发现，operation的状态比较复杂、并且paramter和operation又存在着从属关系，所以我又单独写了一个myoperation类，用来管理它下面的parameter和存储operation的各种属性。
在写完自己的这两个类后，我又在myumlinteraction的构造方法里，对element进行分类，并写了构建相应的myclass和myoperation的方法，将uml图的信息按照我上面所说的三层从属关系组织了起来，之后再实现umlinteraction里的各种方法就显得水到渠成了，只需要根据需求去访问各种信息。
最后在完成了整个程序后，我又针对程序的性能做了一些简单改进，即在一些复杂的方法前添加一个hashmap用来存储之前已经查询过的信息，这样在实际运行的过程中就可以实现缓存的效果，让程序越跑越快。
但是非常可惜的是我这一次作业出现了一个非常致命的bug，由于对java8了解的不够和没有好好看通知群，导致我认为接口和类一样，也只能单继承，这就出了大问题，导致出现接口多继承时，所有对实现接口进行查询的方法都会出错，这实在是非常惨痛的一个bug，它的糟糕之处在于这个bug不是粗心，而是我对对象之间的关系理解就不对，也就是说我从“根”上就错了，这真的给我留下了很深刻的教训。
第二次作业
还是先上类图：
这一次的作业主要是增加了状态图、顺序图查询和三条规则检查的功能，其中状态图、顺序图查询的实现比较简单，仿造上一次作业的思路，我整理出transtion、state与statemachine之间的从属关系等，写了两个方便自己使用的mystatemachine类和myinteraction类，再在之前代码的element整理分类部分添加上对应的部分就解决了问题。
至于三个规则的检查，实际上和整个程序的其他部分也没有太大的关系，通过合理调用之前组织的结构，采用递归的方法实现了规则检查的功能。
但是由于这次的指令种类很多，所有的需要override的方法都写在mygeneration里有点过于臃肿，所以我又将计算的过程全部单独写到了一个build类里，让mygeneration类看起来简洁明了、逻辑性强。
这次出现了两个bug：
一个是在寻找接口重复继承时，忘记传入当前类的id，导致最后就算查到了当前类存在重复继承，也只会记录顶级父类的接口重复继承错误，通过加一个当前类的id的参数解决了这个bug
另一个错误是在寻找循环继承的过程中，忘记设置跳出路径中途出现的循环，导致遇到路径中间出现的循环时会死循环，通过加入一个已经走过路径的set作为参数，再加上循环条件解决了这个bug
这都是在设计算法的时候没有考虑到特殊情况、边界情况造成的。所以看来想要练就不出bug的思考能力还有很长的路要走。
总结自己在四个单元中架构设计及OO方法理解的演进
第一单元
第一单元的时候实际上完全没有什么架构设计，每一次作业都是针对那一次作业的需求完全重构的，所以感觉当时每个周压力都很大。而且当时也不会使用set类，只会傻傻存list，总之当时整个代码给人的感觉就是直接粘到C里也能编译这样，是在后面的分享课上学到了各种神奇方法之后，代码才逐渐OO起来。
然后第一单元对OO方法的理解实际上最深刻的是对继承这一机制的理解，我觉得多项式用来练继承真的是太妙了，因为因子、单项式、多项式之间的关系去深究是非常有意思的，有点数学归纳法的感觉，通过理清楚他们实际上在继承关系里属于同一层次，然后在求导过程中会互相转化，就很好的理解了继承，并且顺带用继承实现了相对来说很复杂的递归（因为要来回递归）。
第二单元
从第二单元开始我感觉其实就轻松很多了，因为从这个单元开始就能够做到，上一次写的代码可以复制下来直接在下一次作业当中直接用。
这个单元的架构设计的色彩就浓的多了，采用了老师讲的生产者-消费者模式、单例模式等，写完之后这个程序看起来规范多了，而且使用前任钻研好的方法也大大避免了出bug的可能。
这个单元学到的主要知识主要是多线程之间的知识和设计模式的知识。前者是java的重要特性，后者则让我的代码终于从野路子走上了名门正派的模样。
第三单元
这一单元我真切的感受到：JML是真的好啊！拿着JML写代码、测代码的体验真的是太棒了，不会出现理解误差而且很容易进行架构设计。
但是我同时也知道，这一单元实际上是想让我们学会设计与实现分离的思考方式。我觉得通俗的说就是，如果我们拿到一个任务，能够先从设计的角度写出合理的JML，那么我们码代码的体验就会像这个单元一样----特别爽！但是能够写出好的JML是很难的，还是需要以后更加多多努力！
同时这个单元还有一个重要的主题就是时间复杂度的控制，通过对时间复杂度的考虑，我也学会了“缓存”的思想，这让我的代码又和实践工业中的代码更近了一步。
第四单元
第四单元的架构设计上面已经总结过了，那么主要谈谈学到的方法：通过这一单元的学习，让我具备了读懂和判断UML图是否正确的能力，相应的我觉得自己也有了根据UML图编程的能力。当然我也学会了画UML图，但是现在的正确率总还是有点缺失，还需要以后进行改进。
总结自己在四个单元中测试理解与实践的演进
第一单元
主要是鲁棒性测试（WF）、压力测试（正则表达式爆栈）、边缘测试。
测试的主要方法是自己构造奇怪的数据来测。
第二单元
主要是线程安全测试。
测试的主要方法升级了一下，由于这个正确性还比较好判断，所以有了对拍的测试方法。
第三单元
主要是单元测试。
单元测试让程序的测试更加分离、可靠，然后也通过像讨论区里学习，学会了JMLunit自动生成测试样例的方法。
第四单元
这个单元主要还是测的一些比如接口多继承、类重名等特殊情况的测试。
其实感觉这个单元理解题意理解对了，比测试的效率高得多。
总结自己的课程收获
这学期的OO课程体验真的很好，感觉课程引导做的很好，每次都知道老师和助教想让我们训练什么能力，然后也有讨论区、研讨课这样的渠道来深入学习这样的能力。很多收获都在上面写过了，写一些没有写过的收获：
码力大大提高，从以前觉得300多行就是一个很复杂的程序，到现在能够写出1700多行的程序。
debug能力大大提高，因为写得多了所以自然就提高了。
学习能力大大提高，其实课程很好的一点就在于很多知识是给的链接而不是直接写好了给我们，让我们有了自己去查去了解这一步（有些别的课程也需要自己去自学一些东西，但是他不会告诉你应该学什么，这就很讨厌）。
立足于自己的体会给课程提三个具体改进建议
（这学期OO课程体验真的很棒了！重要的事情再说一次！！！）
（1）希望以后各班级之间的研讨课内容可以共享：比如把PPT放到github上，或者研讨课进行录像，放到B站上让大家看，因为我觉得研讨课好多大佬讲的是真好，如果一学期能把每个班的大佬的研讨课分享都学习一下，其实多学了好多知识。
（2）希望以后能够提供测试性能的接口，比如第三单元测时间复杂度，大家猜来猜去猜了好久，都怕被T了
（3）希望实验课能不要在理论课上完相关内容后马上就考（因为实验课的题其实挺好的，在没弄懂的情况下就做有点浪费？？？）
最后衷心希望OO课越来越好！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
