第一次作业
这次作业针对一个类图，要实现的功能比较多，但是普遍都是简单的查询方法，且只有一次构造方法，没有更新方法。所以我采取的策略是面向每一个要实现的功能，针对性地设置缓存容器。在构造方法里面对每一种类型的元素针对性的分类储存，只缓存之后要查询的东西。
总体来说，这次的设计比较失败，只有一个类MyUmlInteraction，其中设计了很多的HashMap，用来储存各种针对性的数据。具体而言，有储存接口id的、储存id和name转化的、储存类和其中的操作的、存储类和其中和属性的、储存类当中非private的属性的、储存类操作中没有参数的、储存类操作中没有返回值的、储存继承关系的、储存实现关系的、储存关联关系的。这样的架构……好叭基本上没有结构，比较直观来看就是臃肿，构造方法有一百多行。当时主要是觉得这样比较直观，担心会出现第三单元那样大量tle的现象，就采取了这么一种笨办法。
第二次作业
这次作业增加了两种新的图，如果还是像上次那样直接堆在一个类里大量的缓存也不是不能实现，但是那样代码实在是太丑了，完全没有逻辑和可读性，所以我果断重构了一下。根据三种图的具体结构在每个层次设计了具体的类管理。最顶层MyUmlGeneralInteraction,它管理着三个类分别是 ClassChartManger、CollaborationChartManager、StateChartManger，对应着类图、顺序图、状态图。在每种图中又下辖其独特的元素和查询方法。值得一提的是在类图中，将关系的管理单独成了一个类，主要目的是区分，因为类图中的各种关系很多，都混在大类里比较杂。整体是还是采用针对性缓存的思路，这样可以极大的降低出错率和时间复杂度。也很方便下一次的迭代开发。
第三次作业
这次作业的实现很简单，因为我之前已经针对各种元素进行了针对性的缓存，所以直接在每一个类里面按照要求的查询方式进行检查即可，新增工作量很小。其中对于顺序图没有检查，对于状态图的查询只有检查，直接加到了状态图管理类当中。对于类图的检查比较多，单独划分成一个类，再从类图中选取需要的容器传给检查类的方法，这样做到了封装。
二、在四个单元中架构设计及OO方法理解的演进
第一单元
第一单元是多项式求导，我在这个单元刚开始的时候还是比较不熟练的，刚开始作业设计代码完全是面向过程的，这也就导致了我每一次都要重构。反省原因，认为应该是这个单元的精力大都用在了优化最终结果长度上，自身对于代码的结构要求不高。但是在写第三次作业的意识到了这一问题，学习了工厂模式以及代码的层次化构造，第三次作业初步有了面向对象的样子。
第一单元的架构比较简陋，又经过了两次重构，在此简要分析一下我第三次作业的架构。第三次作业整体结构上，构建了表达式类，项类。采用工厂模式构建因子类，因子类是一个抽象类，只提供了抽象求导方法，共有常数因子、幂函数因子、sin函数因子、cos函数因子、表达式因子五类继承自这个类，并重写了求导方法和tostring方法。这样的好处是代码的逻辑很清晰，工厂模式的使用也方便了之后再添加其他因子。
总体而言，这个单元我对于OO的认识还仅仅是简单的类的构造和继承关系的运用，并没有做到很好的理解，整体的代码架构也是偏向面向过程的。
第二单元
第二单元是以电梯为载体的多线程编程。在这个单元开始我是很懵的，完全不了解什么是多线程，在经过了理论课的学习后，大脑里初步建立起了消费者生产者模式的结构。在编写代码时，开始动手之前会先进行结构的整体把握，尽量的使用面向对象思想，做好代码的封装。在第二单元当中我首次体会到的迭代开发的快乐，当时的感觉是很开心很开心的。这个单元还有一个要着重注意的地方是线程的安全性，我在第二次作业的时候出现了死锁的问题，当时检查了好久，给了我一个大大的教训。除此之外，这个单元在算法的优化依旧下了很大的功夫，虽然最后结果不是很满意，但是这个学习调度的过程让我收获了很多，在OS学习当中也有帮助。
第二单元的作业我整体是采用了生产者消费者模式，构建了生产者和消费者两个线程，两者共享一个托盘&调度器类。这样的好处是运用了已有的生产者消费者模式，比较容检查代码中出现的问题。另外，托盘没有单独建一个线程也大大降低了出现线程安全性的风险。
总体而言，这个单元我对于OO的认识深刻了很多，另外还学习了多线程相关的知识。多线程是以后工作中常常用到的工具，掌握多线程编程的知识、线程调度与线程安全的知识个人感觉收获是非常大的。整体的代码架构也初步有了面向对象的样子。
第三单元
这一单元真是痛并快乐着，快乐是指这一单元的编程压力不大，比第二单元轻松很多。规格已经全部给定的非常详细，基本上不需要自己考虑架构的问题。痛是指这个单元对于算法复杂度的要求很高，并且中测基本上没有给出反馈，导致在强测中很容易出现大量tle的情况。我在前两次作业中比较小心，尽量采取了高效率算法+缓存的方式，强测没有出现问题。第三次作业出现了很大的失误，强测超时了很多。
第三单元的作业代码架构已经基本给出，要求的是我们读懂JML并实现的能力。我基本上没有什么大的架构，主要采取的实现策略就是高效率算法+缓存。值得一提的是，这三次作业务必不能单个函数完全按照JML的规格实现方法写，必须有自己的高效实现方法。JML仅仅是告诉我们要实现的功能，其表示功能的算法完全不具有可参考性，不然就是惨烈的超时问题。
总体而言，这个单元锻炼了我的阅读使用JML的能力，未来在工作或者是与人合作开发的时候，人与人之间的交流协调尤为重要，JML提供了一个很好的媒介。除此之外，我对于OO的理解也在加深，对规格化编程的认识更深了。
第四单元
这一单元又是全新的世界，对于UML图的解析考察的是我们的抽象理解能力，关键是要能正确分析清楚各个元素的层次关系，对面向对象编程的能力要求极高。虽然这一单元表面上看要实现的功能无非是个解析器，比第二单元简单很多，但是想要做到写好写条理还是很难的。
第四单元的作业架构主要思路就是模仿UML类图的层次关系，按照类图、顺序图和状态图分成树的三个大枝，每个大类里面再按照其自身的逻辑结构继续细分小枝，最终形成一个树状结构。这样的思路很好的体现了这一个学期以来一直强调的面向对象设计思想，做到了高内聚低耦合。
总体而言，第四单元不仅是训练我们理解分析UML类图的能力，更多的是对我们一个学期以来OO学习的成果检验，同时在检验过程中，我的设计能力，分析问题的能力都得到了很大的提升。
三、在四个单元中测试理解与实践的演进
在第一单元的测试中我采取的策略是：先测试一下基本功能是否实现，然后随机生成一些比较复杂的数据，或者是边界数据进行测试。这样的方法效率比较低（因为是肉眼对拍），但是通过极限测试还是能发现不少的问题。
第二单元开始接触自动评测机，通过自动生成大量的随机数据，与同学对拍运行结果。这样的好处是效率很高，一晚上能跑几十万的测试数据。覆盖测试也能把程序的问题基本上全找到。但是容易忽视一些极限情况带来的问题，还是需要手动加以补充。
第三单元是测试能力上极大提升的一个单元，JUNIT的使用提供了一种在idea上直接就能使用的测试方法，非常的方便直接。通过代码旁边的颜色条还能检查哪些代码段没有被测试到。但是JUNIT的一个比较大的问题就是想运行大量测试用例时的捉襟见肘。所以这一单元我依旧采取了随机生成测试用例并对拍的形式，两手准备让测试更加充分。
第四单元由于输入数据的复杂性，随机生成数据基本不可能，这一单元我更多的采用了针对性地测试方法，通过手画一些特殊的测试样例图，导出后进行测试，针对每一个方法和异常依次进行测试，取得的效果比较好。
四、课程收获
不愧是从上个学期就听说的OO课程，每个单元的要求给人的压力是非常大的。不过，正是这种高压环境很好的训练了我的编程能力和逻辑思辨能力。我从刚开始甚至对java都不很熟悉的无知者，变成了现在对面向对象初步理解并能简单运用的入门者，自我感觉是收获很多的。
面向对象是一种很重要的编程模式，它提供给我们的是一种结构化、层次化、模块化的架构，实现起来非常舒服，debug也很容易定位。相信我以后在学习工作中一定会用到很多。
除了课程本身传授的内容，我认为我变化最大的是抗压能力。快节奏的课程周流程给人的不仅仅是知识的提升，还有极大的压力，一周一个新开发着实硬核。这期间我很多次都感受到了头疼感，新功能要学习，代码还要一点点实现，另外还是其他课的任务。现在一路披荆斩棘走来，感触最大的就是那一次次锤炼的坚强内心。
另外还有一点我想提到的就是精益求精的精神。我们的前三单元中都有对性能的要求，代码不仅要写对，还要写好。效率高的程序才是一个健全的代码。有很多次我在写作业的时候，时间的重头都是用在了优化上。在当前这个竞争压力大的社会环境，只有不断提升自己，对自己高要求，才能做到不被淘汰。
五、三个具体改进建议
1、实验课的个人成绩以及个人出问题的点应该公布。我对于实验的训练结果一直是懵的，也不知道自己做对了没，理解对了没。公布了实验结果可以更好地帮助同学们理解相关的知识，做到查缺补漏。
2、第三单元的中测太弱，希望能增强一下中测强度。不要出现中测随便过，强测全是tle的情况。这一单元的失分实在是太多了。
六、线上学习oo课程的体会
线上学习有利有弊。
好处是腾讯课堂的课可以反复的听，要是有不理解的可以多学几遍，这样很好的改善了在学习听课老师只给讲一遍的问题。另外线上学习的时间也灵活了很多，可用在OO上的时间变多了。
弊端是同学们之间的交流不顺畅了，以往在学校可以很高效地面对面交流，但是现在只能云聊天，效率降低了很多。另外就是网上上课的积极性和互动性降低了不少，以研讨课为例，越往后听越觉得同学们之间少了很多的交互。