第四单元博客作业
一、总结设计架构
第四单元的设计目标是一个针对uml的解析软件，根据输入的uml类图、顺序图、状态图，根据不同的指令反馈出不同的信息，同时最后一周还追加了对于各种图的规范性检查。
总体来讲第四单元的难度较低，再加上没有互测，可以说是快到期末的一次难得的放松了（感觉OO第一单元反而是最难的
1.第一次作业
第一次作业只需要考虑uml类图的情况，由于在我的印象中类图是一个整体的概念，所以除了Main类以外我就只设置了一个类：MyUmlInteraction，继承UmlInteraction，用来存放所有的类图信息，并且响应相应的指令。
在类中，因为考虑到需要大量的查找，于是采用了Hashmap的形式来存储数据，这样在进行大量查找的情况下，即使不设置相应缓存，也可以有较低的时间复杂度。
如上图所示，针对不同的Element类型分别设立对应的Hashmap，key值的选择则是根据查找的需要，比如associationEnd需要通过reference，也就是所对应的类来查找；generalization的话因为需要从子类出发找父类，就是选择source作为key值。而像association这种只需要通过id来查找的就放在allMap中，因为id肯定不会重复也不需要考虑重复ID的情况。
2.第二次作业
第二次作业在第一次作业的基础上新加了对于uml顺序图和状态图的存储和查询。在此分别开设了了两个新的类用来存储对应的状态图和顺序图的信息，然后再用一个MyUmlClassInteraction来统一管理三个类。综合后的UML图如下：
另外两个类采用类似于第一次作业的存储方法，将数据根据查找的key值存储在相应的Hashmap中。
第二次作业的指令要求比较简单，基本上实现了需求也不会踩进什么坑里
3.第三次作业
第三次作业增加了对于uml规则的要求，要求程序能够判断给出的uml图信息中存在的不符合规则的情况。对此，新增一个Checker类专门用来进行规则的判断。
其中，一些简单的判断可以直接在对应的class内部实现，复杂一点的判断，例如需要dfs去找继承关系的R002等，交由Check类来执行。（其实是因为行数超了）
二、四个单元中架构设计、OO方法理解的演进以及测试理解与实践的演进
1.第一单元
第一单元是最开始接触面向对象编程的一个单元，虽然有预习任务的铺垫，对于java语言的书写没有太大的问题，但是由于之前都是面向过程的编程思想，导致写出来的代码基本就是“写在class里面的面向对象程序”，也没有考虑类到底是个什么东西，类之间的关系、架构到底是怎么样的，所以导致第三周作业的彻底炸裂。
第一单元的测试内容基本都是手测，然后构造一些极端数据，然后根据保留下来的自己的测试数据去互测里刀别人。测出BUG后进行修复的时候，也基本不会从对象的角度来考虑，而是大多数情况下写一个新的方法来实现。这就导致最后的代码中有一大堆复杂的方法，最后的类复杂度高得吓人，而且还有Method这种专门用来存静态方法的类出现，可以说是确确实实的在对象中实现面向过程了。
2.第二单元
第二单元接触了一个重要的概念——多线程。多线程的编程是在过去的C语言学习中从未考虑过的，可以说是一种全新的体验，同时也接触了线程安全、锁等重要的概念。多线程在设计的时候，比起之前的代码最大的难点在于不能像以前那样轻松的debug了，而且如果还是像过去那样完全按照面向过程的方法来的话，在三次迭代开发的最后肯定会死的很惨。
在第二单元的作业中，比起第一单元的作业，我进一步地理解了对象的含义。相较于第一单元的多项式，因为第二单元有个更加直观的对象概念——电梯。把电梯作为对象，不同电梯之间并发运行，然后和中央调度器之间进行交互，就是这样一个清晰的模型概念。在完成了第二单元的任务之后，再回过头去看第一单元的任务，就会找到更好的优化方法。总的来讲，面向对象编程中一个重要的环节就是抽象出任务中的对象，然后建立对象之间的关系，以此为基础来构建自己的代码。
第二单元的测试和debug因为多线程的缘故和比第一单元麻烦了不少，而且要考虑在特定的时间进行输入，纯手工的输入测试已经无法实现需要了，需要想别的办法来完成测试。我尝试过自己写输入代码，但最终不了了之，还是靠着同学抬了一手。这也让我认识到了学会自己写工具的重要性。
3.第三单元
第三单元解除了jml，一种对Java程序进行规格化设计的表示语言。让我充分了解了规格化设计的相关内容。经过前两个单元的洗礼，加上本单元给出了相应jml的特点，设计程序的过程中在对象抽象方面没有遇见太大的问题。感觉第三单元最需要的就是读懂jml让我们干什么，然后用最好的方法来实现，如果照着jml写的话就会导致时间复杂度或者空间复杂度过高。
通过第三单元的设计，我对面向对象中对象的封装性有了更进一步的的理解。好像物理学中的黑箱一样，面向对象过程中，对于一个特定的对象，我们只关心它得到什么样的信息会反馈出什么样的信息，而对于其中的具体实现方法可以千奇百怪。这也是为什么类中属性可以保持private的一个原因。对于一个黑箱，我们只关心它暴露出来的在外的接口，而不关心它的内部，对于一个对象也是如此。
第三单元的架构不会有太大的问题，在测试的时候不会去考虑架构的问题。同时，第三单元中还接触到了junit单元测试的方法。按照jml写对应的junit的测试代码，通过junit单元测试，可以测试设计是否能满足对应jml的需求。
但是我要吐槽一句的是，OO第三单元我强测错的分，都是之前学数据结构时脑子进的水。
4.第四单元
刚刚做完的第四单元，重点是在uml上。之前单元总结的时候要求我们加上uml类图，我那时觉得uml类图就是对java写完代码的另一种表示而已，但是在学完第四单元后我发现自己错了。uml可以说是另一种面向对象的语言，通过uml类图我们同样可以构建一个面向对象程序，只不过这个程序是给人看的，不是给机械看的。也可以把它理解成面向对象代码的一个大体框架。比起直接上手写代码，如果先构建了uml类图，就能对自己要完成的代码有一个更加清晰地认识，而且在优化自己的设计架构的时候，通过uml能够更加清楚、直观地进行修改。、
uml图比起java的代码能更加直观的体现面向对象的编程思想，图中的一个个class，以及它们之间的继承、实现、关联关系。
第四单元的测试比起之前多了一步，通过jar包导出对应的uml图，然后再和指令一起作为输入。通过四个单元的测试，我感受到了不同单元的测试有着不同的需求，其中有些是纯粹的人工无法实现的，如果掌握了编写自动化测试脚本的能力，可以根据每个单元不同的需求自行修改，就可以很方便的完成测试。不仅比手工测试花的时间少，最后代码的质量还会更高。
三、课程收获
学完了OO课程之后，最大的收获肯定是学习了一种新的编程思想，和过去面向过程的编程方法不同，面向对象的编程在很多问题的编程上有着完全不同的思考角度，也会让程序显得更为简单和易懂。比如如果让我用C语言写一个多项式求导可能会显得更加复杂和难以维护。
在此之上，面向对象的核心其实是一种抽象能力，如何从问题中抽象出对应的对象，对象之间的层次和对应的关系，这些都是能否建立一个好的架构的基础，而一个好的架构往往能让你在写代码的时候事半功倍，最终写出来的代码也会质量更高。
在设计架构的时候，需要考虑到的不仅仅是目前的这些需求。如果为了满足目前的需求而在一些地方采用偷懒或者取巧的办法，就会导致代码的可扩展性极差，在后续新的需求追加的时候就需要对原来的代码进行大规模的修改，甚至需要重构。代码的可扩展性也是之后在设计代码的时候需要考虑到的一个重要的因素。
最后，通过OO课程的学习，我还认识到了设计良好的测试程序是多么重要的一件事。程序不能只求过了一些简单的样例就满足了，边界测试、压力测试、大规模随机数据的测试都是极为重要的。就和上学期的计组一样，如果只是过了课下的中测（弱测）就去上机的话会死的很难看；OO如果只是过了中测就满足的话会在互测里被刀得千疮百孔（甚至进不去互测）。一定要自己做足了充分的测试，这样才有进互测的勇气和刀人的功力。
四、改进建议
1.个人感觉OO课上的内容和实际的单元任务有部分脱节的现象。就拿第四单元的内容来说，在一开始看视频的时候，没有经历过实践的话完全不能理解uml那些一大堆乱七八糟的属性，就导致上课的时候体验极差；然后就算在课上完全没能理解的情况下，最后也能完成课下的对应作业。这是我觉得课上课下有点脱节的部分。
2.希望之后实验课不仅仅只是给出通过数据的分布，同时也能公布答案或者是个人具体的得分。没有反馈的话根本不知道之前的那些想法是否是正确的。做完课上实验没有得到反馈真的是很让人迷惑的一点。
3.互测发展到最后变成了看各位大佬之间通过自动测评机互相刀的模式，和一开始说的互相看代码，学习其他人代码的同时发现它设计上的漏洞完全不同了。虽然没有写测评机的同学仍然可以通过后面的方法来刀人，但是这样子得分的效率肯定远不如前者，说难听点就是有点出力不讨好了。这种纯粹为了得分而进行的互测是否有违背了一开始设计互测的初衷呢。
五、线上学习OO的课程体会
线上学习和线下学习最大的不同就在它的灵活性，特指观看课堂视频的时间分配上，可以提前看、可以分开看、可以反复看。上面提到的课上和课下不同的问题也可以通过延后看视频的方式来加深理解。此外，线上学习能够更加锻炼我们的自主学习能力，不会一遇到问题就直接转头问室友，会自己先想办法找资料和课件进行解决。
但是线上学习有一点明显的坏处就是会极大地降低同学们的讨论积极性，课堂上问题的讨论每次都是那么几个同学发言，最后还需要老师来点名回答。分享课也是同理，感觉比起现场课同学们会更加拘束一点。