OO第四单元总结
OO第四单元总结
随着第四单元（最后一个单元）的结束，也宣告着OO课程接近了尾声，第四单元紧跟着第三单元也是有理由的，第三单元学习的是JML的相关知识，而第四单元学习的是UML的相关知识，也就是从读伪代码的注释到读图了，UML也算是一个确定架构的重要工具了，所以要好好学习。
第一次作业
前面说了这个单元学习的是UML，第一次作业需要我们实现的是一个UML类图分析器UmlInteraction，要做到对类图的元素的解析，首先我们要明确有些什么元素，这就可以去官方包里找那些需要的UMLelement，在分析器这个类一开始的解析阶段，我们可以分类别进行加入到各自的容器中，以方便后面的查找等操作，也有利于之后的一些需要完成的方法。
因为这个单元的作业基本算的上是迭代开发了，不怎么需要重构，当然有很多不完善的地方，需要重构来简化。因为是迭代开发，所以每一次作业都很重要，前一次没了，后一次也别想过，所以每次都得弄过了。
第一次作业的架构如下：
因为第一次作业仅仅是对类图的解析，所以我们只需要把类图的元素分好类，封装好就可以了。
第二次作业
第二次作业加上了对顺序图以及状态图的解析，然后一些里面情况的查找的方法。对于加的2个图，顺序图就像是一个流程，完成一个任务需要几个什么对象参与，然后需要他们按照什么顺序，执行什么方法，每个对象都有一个生命线，直到最后完成任务；而状态图就像我们之前在计组中学过的状态机，就是一个对象在多个状态之间的迁移，通过一些触发条件、动作等进行状态的转移。
前面也说了这个单元确实是迭代开发，所以仅需在第一次的基础上添加几个我们需要封装的类，然后在分析器类里加入一些方法。
下图为第二次作业：
第三次作业
第三次作业据说是今年新增的，去年应该是只有两次作业，这无疑给疫情期间在家学习的我们增加了本没有的压力，“让本就不富裕的家庭雪上加霜”。这次作业需要我们新增的功能是检查模型的有效性，有8个检查有效性的方法，其中有几个是比较难写的，因为又涉及到了数据结构的一些与dfs有关的知识，需要不断的尝试与改正。
第三次作业的架构与第二次相同，就不再放图了。（方法太多了看不清了都...
这样看来，这个分析器类其实是写的很不好的，也就是说，我这个架构，跟我这样来写的话，好处是比较简单明了，东西都在这里面，但是缺点是太臃肿，而且代码风格会出问题，也是因为自己懒，不愿意重构来解决这个问题，但还是建议分开封装一些方法，这样会让程序显得更加精致。
总结
经过一个学期OO课程的学习，终于体会到了这门课程能给予我的痛苦，确实是被OO支配的恐惧，因为一开始不适应线上学习，从一开始就有点掉队，然后心态问题也很大，慢慢地也就习惯了这些，毕竟是没有办法避免、没办法逃开的，所以后面虽然心里“骂骂咧咧”，但是心态还算是比较稳的，我觉得相比于知识的进步，心态上的进步是我觉得更珍贵的。当然，知识也得到了很大的进步，因为之前也没接触过Java，这个学期一开始就那么大的工作量，也是逼着去学习这门语言，现在一个学期下来，也算是能进行一些基本的操作了，所以知识上是获益匪浅的。
对于线上学习，效果确实没有在教室里坐着那么好，也没有坐在寝室里大家一起讨论问题的那种氛围，这是对我们学习效果的一个打击，但一个学期也是坚强地挺了过来，现在就是希望疫情赶紧结束，让国家回到安全的状态，让大家都可以回去上学，让萌新们可以安全入学。
具体改进建议
说到提建议，那我一直都是很被动的，既然硬要提的话，那么第一个就是希望前期的指导多一些，也就是课程上讲的内容，讲到作业的方面多讲一些相关的知识，想法等，让大家可以快速入门；第二个建议呢，难度的增幅不要太大，不要第一次作业就上天，或者说第一次比较简单，第二次就上天，还是循序渐进比较好；最后一个建议就是希望课程机制可以进行一些改进吧，给学生的压力不用再加大了。
