OO第四单元总结
前三次框架
前三次框架由于第一二次做的比较顺，基本没有牵扯到重构现象，都是接着上次去写，所以这次主要着重第三次作业分析。
主要是对通过对已经存在着UmlElement的一个子类，并对其进行扩展，增加它的方法，并且在UmlGeneralInteraction进行对Umlelement进行管理并建立关系，且调用UmlElement子类的方法完成。
第一次作业
主要是在类图中进行查询操作，主要牵扯到class、interface、operation和attribute和parameter。首先class有父类，有实现的接口，管理的属性和方法；interface有父亲接口，管理的属性和方法。对继承、属性、方法、参数、实现、继承等关系遍历，将所有的信息存储到上面四个类型中。每次调用就在查找对应的元素就可以了，并且需要对一些内容，比如所有实现的接口、所有的祖宗类进行记录。
第二次作业
增加了状态图和顺序图，牵扯到了lifeline、message、state、region和machineState和transition。同样是遍历相关信息，将所有内容存储到相应的元素中，在调用的时候查找对应的元素完成操作。
第三次作业
由于第一次作业查找实现的接口、祖宗类都是需要不能有循环的，所以选用了一个新的属性去存储是否有环等内容完成error的判断，不干扰第一次的内容。第三次作业也是在第一二次作业下的结构进行增加内容的，所以基本是只增加了一些方法。
书写的时候感觉有如下几种更好地修改，要不然是懒（主要担心更改后引入了新的bug）要不然是不是很清楚操作没有完成。
- 由于不是很清楚怎么利用父类的实例转变为子类的实例，所以使用MyUml** 重新维护了一个Uml*** ，然后把一些常用的方法再去调用本身的方法。（本意应该是继承，但是最后用了association）。应该想办法用继承去完成这些内容。
- GeneralInteraction有对类图、顺序图+状态图、error三个判断，我觉得最好是在GeneralInteraction完成对输入数据的管理并建立关系，然后通过实例化三个分别对类图、顺序图+状态图、error的调查的类，并传给他们有用的数据，通过这些对象完成。将GeneralInteraction的功能分化为4个。最后是error完成了这个操作，然后类图和顺序图+状态图还是放在了UmlGeneralInteraction里面。
- 对于数据保存是每一个类型一个hashMap，应该可以用HashMap<Type, HashMap<id, UmlElement>>，进行管理，不用许多else-if判断类型之后再添加进去了。（忘记在哪里看到某个同学的想法了。。）同样这样对
- 每次作业都是在上一次作业上进行修改，而没有迭代，是不是可以对每个类进行继承在子类进行修改，这样子就更好地完成了面向对象的思想？。。（个人理解是这样的。。在课程结束的时候发现了。。）
第三次作业的分析
没想到自己的UML会这么丑。主要还是上面的第二点搞得。所有做了以下更改。
- 自己对程序进行了针对第二点的修改，可以稍微大致看清楚UML的元素的层次，但依旧感觉很丑。
- 同时现在的GeneralInteraction是将所有数据全部初始化放在里面，如果用一个类去保管所有的数据，并且同时有一个内部工厂类对UMLElement，同时三个将GeneralInteraction功能分化的三个类通过数据类去调用数据类完成操作，应该可以降低类之间的耦合。
以下还可以进行更改但是由于会大幅度更改功能性内容所以没有操作。
- 从分析角度来看，Class和Interface应该也可以进行一些优化，主要是第一次作业和第三次作业有些重复的数据可以用一个属性或方法进行管理。（没有操作）
- 对数据的初始化也可以通过HashMap<Type, HashMap<id, UmlElement>>用进行优化，应该可以再去降低现在初始化的复杂度。
以上两点都是针对方法复杂度去进行的修改。
改变之后可以明显分出四个层次，第一个是interaction，第二个数据Data，第三个是完成相应功能的类，然后后面是所有UMLElement的类。
这是复杂度的部分变化（new/old）
对于generalInteraction方法的复杂度有很明显的降低（主要是利用那四个类去辅助完成），同时平均复杂度也有一点点下降。对于一些非常复杂的方法由于没有改变根本逻辑还是很复杂。
四个单元中架构设计及OO方法理解的演进
第一、二单元其实有去看往年的题，做的时候就有在想之后会怎样可以避免重构，但是基本没什么效果。感觉完全就是针对每道题去写，尤其是求导，当时对于“类”的概念都比较模糊，着重在思考怎么去维护数据，每个类保护什么数据，类和类之间要有什么样的关系（现在看是在构想uml的问题，但是当时啥都不懂）。在电梯中利用了观察者模式+类似的生产者消费者模式，感觉明显框架结构好很多，不在纠结于每个数据，而是在想整个框架大概是什么样子，可以一层层的去分析问题，从最开始怎样完成调度器-队列之间的问题，然后再到电梯怎么去处理队列，感觉可以从模块化去思考问题（但是又牵扯多线程二者在一起还会出问题），但是基本没有怎么理解面向对象的思想。
第三单元对于JML其实是做完最后一次作业de过bug才明白jml的精髓，之前完全陷进表达式了。应该是jml-需求-功能，但是我没有考虑需求而直接希望用jml就实现功能，导致了很多很多问题。而且面对这个问题应该重构，但是偷懒了没有，导致第二次作业和第三次作业完全雪崩。
第四单元其实我觉得jml和uml某些层次上还蛮像的，一个是描述功能，一个更像是描述框架，而且作业也是基于框架去完成一个功能。所以基于功能去思考，思路就比较清楚。有了第三单元血的教训第四单元完成的还是非常顺利的。
面向对象我觉得核心应该是几个原则，就是SRP、OCP、LSP、ISP、DIP这些。但是因为毕竟还有三次迭代没有那么多，而且第三次作业基本就不用再去维护，对于几条性质一般都是在总结的时候发现问题的，或者是在设计框架的时候会去思考，实际码代码或者debug的时候就不会去思考这些问题了。所以迭代之后一定程度上框架会变化，之前设计的蛮好的东西之后需要很大程度更改，但是偷懒没有，就会导致一些原则完成的很差。（就像我之前根本想不到第四单元UML会那么恶心一样）
感觉第四单元是基本满足我理解的面向对象的思想的，主要原因也是因为第四单元大多是填空，而第一二单元是自己写解答，所以第四单元本身可以发挥（或者不体现面向对象思想的地方）余地就没有很大。自己主要更多的去思考LSP、ISP、DIP这些，毕竟这些是给的源码和自己代码的关联。
对于每个规则的理解都是递进的，之前对于“继承”其实就是感觉子类是父类的一种情况，或者是添加了一些条件，但是对于LSP来说其实就是不一定的，满足了父类不一定可以满足子类，因为子类也许会有一些自己的约束导致会出现问题。但这个问题是课堂讨论后才得出的，就是很凑巧这个问题延伸到了这里才有更多的理解。虽然个人感觉理解的不错，但是应该还有非常多的漏洞。
四个单元中测试理解与实践的演进
第一、二、三单元更多关注的是测评机，第四单元完全是手搓数据。一个是因为第四单元测评机还是基于对UML的理解，如果理解有问题测评机就是有问题的，而且很多极端数据其实也测不太到，不如手算复杂度+手搓极端数据。前几个单元测评机是越来越没用，一个也是因为测评机写的不是很用心，另外一个也是因为更多的还是对题目的理解出问题，题目理解出问题，测评机也是错的。
第一单元没什么太多内容。第二单元的多线程更多依赖的是数据自动输入的脚本。过多的依赖测评机反而会导致程序出现大问题，尤其第三单元对时间的把控。当然测评机对于互测还是非常便利的。
Junit基本是没有太怎么用到，一般也都是手搓把大部分数据都照顾到了。JUnit只是写了一次作业的一半，感觉用处没那么大。之前同学分享的时候也提到过JUnit，主要是基于测试的开发，和现在我们这种开发完了再测试感觉差别很大，如果按照同学讲的实际上对JUnit利用的并不是非常好，或者说没有基于测试对代码结构、开发的帮助了。
课程收获
- 对代码整理（无论使用github还是对idea的使用）都更加有条理了。
- 感觉到设计程序框架（主要利用面向对象一些原则）的优势和意义，并且非常明显一次做的比一次更好。
- 对JML和UML的理解，更多的是偏向如何去设计程序，是针对需求设计，而不是针对JML设计。
- 对测试有了更多的体会。（毕竟之前是停留在对程序的检查，很少会做大量测试）并且知道了怎样可以发现更多的bug。
- 通过几次总结也知道怎样去评价程序，并且如何基于这些评价再去改进程序了。（但是很多时候问题发现的比较晚，应该是写程序就发现的问题拖到了后面。）
- 对于迭代开发有一定自己的理解（但肯定还是很浅），有的时候会特意为以后留一些接口或者余地方便之后的操作。但这些主要还是针对对未来题目的猜想，和实际应用还有很大的差距。
- 对很多问题，从如何去提出问题，到如何解决问题，通过微信群讨论有比较深入的认识。
- 对于面向对象和java的相关知识，并且了解了很多设计模式。
三个具体改进建议
- 实验有的感觉非常有意义，比如多线程的第二次作业，以及第一次UML还有一些记不太清的，但是有些实验实际上感觉只是完成任务，就和每次的作业跨度比较大，而且真的有些细节是自己不理解或者是的确是指导书说的不清楚（或者是理解不同）。可能微信群的原因不方便问，导致有些体验很差（我觉得主要还是疫情的锅。。如果上机的话问会很方便。。。）而且是不知道实验结果的，所以有的时候发现了问题自己也不清楚，而且还没有答案，不会做的都不知道结果，只能和同学讨论。
- 其实我个人感觉不如把总结的一部分内容放到每一次作业后面简单的对UML等进行一个分析，就比如通过UML可以看出代码的问题啊，或者框架结构是怎么设计的，就是debug的时候简单的写一下。其实这样在迭代过程中可以更清楚认识自己的问题，而不用到最后才发现问题恍然大悟，然后来不及更改了。但是这样同学们的压力会很大，所以不如只给个平台但是最后还是在总结的时候再汇总。
- 我个人做的时候感觉，第三四单元对面向对象理解是更有帮助的，就他是类似填空的，不如放到前面，然后后面再是自己去设计框架，再去写。或者说前两次作业是更像这种填空的，而后面是直接给功能，然后自己去写一个程序出来，尤其是设计很多种模式，感觉会对整个的理解更好。或者前两次单元不会那么崩溃，后面两个单元可能就有那么一丢丢休闲了。其实我个人感觉求导不动，把多线程放到最后也许会好一点，首先多线程本身不涉及到其他知识，并且电梯那里也讲了很多种模式，学了UML之后对这些模式会有不一样的理解，而且相对来说多线程也是难度最大的。同时寒假作业对于不会JAVA的人太不友好，而且上手也有一点困难，同时和第一次作业难度坡度还很大（缺少心理准备）。