OO最后一次博客作业
第四单元两次作业总结
本单元的两次作业都是围绕着UML的学习展开的。虽然在之前的作业中，尤其是每次的博客作业中，我们也都会用到UML图，但是就如老师所说，我每次都是用idea自带的UML插件直接生成UML类图，而缺少了其中思考的过程。也正是因为每次的懒惰，虽然知道UML类图和顺序图的基本构造，也貌似每次都通过程序的UML类图进行了一些分析，但是其实关于UML最为本质之处还是没有透彻理解。所以，通过这个单元的学习，通过编写对于UML进行解析的代码，可以说，我对于UML类图、状态图和顺序图终于能够有更加深刻的理解。
1.第一次作业
在第一次作业中，我们的任务主要是实现对于UML类图的解析。虽然程序的主干逻辑已经帮我们完成，但是由于对于UML类图元素的不熟悉，这次作业还是有不小的难度。所以，在前期，我也在对于UML类图元素的理解上花费了不少的时间（在此也感谢讨论区的大佬，每次都能够在迷惑的时候帮助我找到答案）。但是，本次作业由于在逻辑上并没有什么难理解的地方，也没有像上个单元一样对于算法效率的严格要求，所以在理解要求后，整个代码的编写还是较为顺畅的。
上类图（虽然我刚开始diss了之前直接上类图的做法，但不得不说这样分析起来的确...很方便）：
在本次作业中，我通过建各种map进行对于UMLElement的存贮，并且对于比较复杂的元素（指其中可能有其他的包含关系，如UMLClass、UMLInterface）建立了新的类，并在其类中存放相应的信息。
除此之外，由于第三单元TLE带来的阴影，我没敢使用DFS等需要递归的算法，而是在继承或接口实现的时候通过继承关系将需要参与继承的类或接口加入一个队列中（这种方法其实有一个前提，就是必须保证没有循环继承）。这样可以保证在将父类的全部信息传给子类（此处以类的继承为例，接口的继承和接口的实现同理）。虽然在数据量小的情况下和其他的算法没有什么区别，但是当数据量大时效率还是比较可观的（虽然这回的数据量都并不大）。
bug情况：
但是虽然上述这种算法比较方便，不用考虑建图之类的，但是由于最初在加入队列时情况考虑少了，导致强测又翻了车（又是不好好debug的锅）。
2.第二次作业
第二次作业重要是在第一次作业的基础上加入了有关状态图和顺序图的分析，并且对于代码进行三种规则的验证。
在状态图和顺序图的方面，总体来说逻辑还是比较清楚的，依照上次作业的方法就可以做个大概，重点还是先理解各个元素的含义（以及各个指令的意思）。（当然这次没有能够躲开建图+dfs的命运，还是乖乖递归了）。
而对于三种规则的验证，规则002和009还是运用了第一次的队列的方法，但是008可以明显地看出是数据结构的可达性问题，于是运用dfs的思想解决了008的检验。
上类图：
可以看出，这次由于数据类型的增加（以及代码*山实在是堆不下了），所以增加了不少的类。类构建遵循的主要规则也和上次作业的基本相同，将有包含关系的元素建成类便于各项的存储。
bug情况：
这次在中测中就遇到了一些情况——最后一个中测点一直过不去。虽然看到了许多同学的解决方法，但是没有一种是适合自己的，毕竟最后一个点应该是一个非常复杂的综合图，所以各处都可能是出错的原因。最后，通过一个较为复杂的图进行测试，发现自己是还出现了不应该的异常ConcurrentModificationException，而这一异常导致的原因是在对hashmap进行遍历的时候更改了原本的map，最根本的原因还是深拷贝和浅拷贝的区别，所以最后的解决方法是将浅拷贝改为了深拷贝。
其次，在强测中还是出现了两个问题：
- 一个是由于对于指令没有清楚的认识，指导书中其实已经说得很清楚——计UMLLifeline的数量，虽然当时也是这么想的，但是在计数是还是通过它们的name进行计数。
- 另一个bug主要是由于在类继承的接口传递时只将父类的接口名称传给了子类，将父类含有此接口的数量直接默认为了1，导致了惨案。
在四个单元中架构设计及OO方法理解的演进
曾经听到选修过java课程的同学说，他们的老师在第一次课的时候就问同学们是否学习过C语言，并且对他们说明没有学过最好，当时我的内心毫无波澜，现在的我回想起来想流泪。
最开始学习编程时老师们都会介绍面向过程和面向对象两种常见的编程方式，面向对象，顾名思义，就是指将事物抽象成对象分别建类进行封装。
由于之前面向过程的思想对我影响太深，所以在很多情况下自己还是将java代码写得非常的面向对象。但是经历了四个单元的练习，积少成多，虽然自己的面向过程思想还是如何在面向对象的代码中，但是对于面向对象的理解还是在逐渐加深的。
第一单元：
第一单元的作业是围绕多项式求导展开的，主要的困难在于怎么正确地将多项式进行各类别的分解。在前两次的作业中，由于数据并不是那么地复杂，正则表达式可以说不失为一个非常优秀的方法，便捷且较为高效，但是到了第三次作业，由于出现了递归的情况，所以只能开始重构之旅，使用局部格式判断的方法对多项式进行分割。
由于刚开始接触面向对象这一思想，所以现在再看前两次作业的代码，我不仅对于自己产生怀疑——这是面向对象的代码？（虽然现在也还有不同程度的这种情况）但是，通过两三个星期的理解和消化，第三次作业的代码可以说是基本做到面向对象，能够将不同的类型进行区分，但是有一个明显的问题是对于几乎完全相似的类，我还是没能完全进行整合，导致代码出现冗余的情况。
第二单元：
第二单元的作业是有关电梯调度的作业，这次的训练核心是多线程的运用。在这三次作业中，我主要是针对当前的情况通过不同的调度算法进行调度，将电梯作为一个单独的线程。在前两次作业中，我使用暴力轮询的方式进行调度，但是这种方式在第三次作业中并不适用，所以我在第三次作业中引入wait和notify，更加针对性地对于线程进行调度。
虽然在多线程的调度上达到了实现，但是代码还是出现了一些没有必要的类，产生了冗余，而且每个类的功能也不是那么具体。
第三单元：
第三单元是有关于JML的学习，三次作业也是围绕着JML规格的实现展开的。但其实在作业实际完成的过程中，我认为给我带来最大困难的并不是JML规格的理解，而是数据结构的正确适用。在第二次作业中，其实如果适用现有的算法，实现是非常简单明了的，但是由于我错估了算法的效率，自己适用暴力遍历完成了作业，导致强测因为TLE爆炸了。在第三次作业中，再一次选择错了方法，导致自己的程序爆栈了，在重构时我将程序改为了不拆点法，并运用两次dijkstra算法计算最小权值路径。
再回看这单元作业的类图，可以看出面向对象的思想还是有待于提高，并且开始出现过于长的类，这也说明在类的划分上出现了一些问题。在很多情况下，我还是只是将类作为一种盛放代码的容器，而没有关注它们是逻辑意义，所以导致面向对象的思想没有很好地进行体现。
第四单元：
见第一部分。
在四个单元中测试理解与实践的演进
从这个学期整体的OO学习来看，我对于代码的测试的严重不足可以说是我经常翻车的最重要的一个原因，有时候一个很简单的错误，并且应该是很容易debug出来的，却使我错了不少的测试点。所以测试对一个程序来说可以算是至关重要，甚至我觉得它比完成代码编写更加重要。
作为一个小白，我测试代码的主要方式还是黑盒测试——如果数据设计的好，其实这种方式不失为一种能够精准打击的方式。所以最主要的步骤还是构造数据。构造数据这一步骤其实应该在代码开始编写之前就完成，根据指导书的含义构造一些边界数据，并在代码编写的过程中时刻注意是否满足这些数据的要求。除此之外，数据还需要保证全面性，在第二单元的作业中，我就是因为在构造测试数据时少考虑了一些情况导致最终的代码出现了一些错误。除此之外，在第三单元中我们还使用了JUnit进行测试，这种单元化测试也使测试范围更加集中化。当然，编写评测机进行测试是一种更加自动化以及全面的测试方法，所以在之后我也应该学习编写评测机，使自己的测试能够更近一步。
课程收获
不得不说，我整个学期的OO历程可以说是一个血泪史，次次翻车并且越来越甚也是让我有点措手不及。尽管如此，虽然说OO为我带来了很多的困难，但是我也通过一次次的练习真切感受到自己能力的提高。
这个学期的OO课程，我认为内容是非常丰富的，课程安排也让我们每周都十分的“充实”。虽然说，OO课程对我们的要求总的来说还是挺高的，但是这些要求也的确在帮助着我改进自己的代码编写，比如说有关于checkstyle规格的规定使我在平时编写代码时也能不自觉地更加注意自己的代码风格，再比如说有关于UML的学习，可以让我能够对于类图等UML图有了只是通过普通使用达不到的理解。
虽然说可能我在面向对象方面做得还是不够好，但是我相信通过以后编写更多的代码，我也会将在OO课上学习到的面向对象的思想不断巩固，能够更好地使用java语言实现买你想对象编程。
对课程的三个具体改进建议
-
关于理论课：
我认为在理论课中可以增加一些有关于面向对象更加具体细节的知识内容，虽然说可能这些细节之处的知识不是从宏观上讲没有能够体现出来，但是对于我这种初学者来说影响还是挺大的。（并且希望以后理论课和实验课可以稍稍调整，能够避免实验课一脸懵逼的情况。）
-
关于作业：
作业总体来说我觉得还是很贴合课程的进展的，只是我认为第三单元似乎与面向对象的训练有些偏离，与JML规格的学习也有些偏离，感觉变成了一个纯粹的数据结构问题，我们所做的就是在考虑如何提高程序效率，而不是如何进行面向对象或者如何读懂JML规格。
-
关于强测和修复：
其实我对于强测的错误点在进行bug修复时再扣一遍分不是非常理解（因为有时候一个错误点可能就已经导致强测严重翻车，要是再扣一遍分就让人非常痛苦了）。