总结本单元三次作业架构
本单元需要在理解UML类图、顺序图、状态图的各种元素以及元素之间关系的基础上解析输入的UML图，构建一个图结构，对输入的指令进行解析并输出查询结果。
第一次作业
第一次作业的架构如下图所示，我对UmlClass、UmlInterface、UmlAttribute、UmlOperation、UmlParameter类使用了对象适配器模式，分别使用了MyClass、MyInterface、MyAttribute、MyOperation、MyParameter进行了包装。举例来说，这样就可以在MyParameter里添加方法isReturn()、isParam()，MyOperation里添加方法isReturn()、isParam()，高度契合判断逻辑，不容易写错，编写体验极佳。
第二、三次作业
尽管第一次作业的架构已经可以了，但是由于第二次作业新添加进很多UML元素类型，如果一一实现适配器，工作量太大，并且这样会使得各个类之间的关联性很强，一个地方写错，就可能全都错了。所以从第二次开始，我修改了架构，改为了设置ClassManager、InterfaceManager、AttributeManager、OperationManager等类来实现对各种UML元素的管理。例如，AttributeManager类就只用管理属性相关的查询，OperationManager类就只用管理方法相关的查询，这样各个类之间的逻辑较为分离，写起来也比较方便。
总结自己在四个单元中架构设计及OO方法理解的演进
第一单元 多项式求导
这个单元中，我对于面向对象的理解尚不深入。由于面向过程的思维仍然占据主导，我对编程的目标拘泥于代码复用。尽管我尝试着对架构进行设计，但最终证明还是不够面向对象。 架构设计并不是简单的抽象共性，还涉及到可拓展性、多态性等等许多需要考虑的方面。在得知具体需求之前，我们很难设计出一个可以应对所有情况的架构。但我们可以尽量把架构的可扩展性提高，减少迭代时需要更改的部分。这是我对于架构设计最初步的认识，架构设计的目标是尽量提高代码复用，将共性逻辑提取出来，以便在需求更改时修改尽量少的代码。除此以外，在设计时，还要注意遵守solid原则：
solid设计原则
Single Responsibility Principle：单一职责原则
Open Closed Principle：开闭原则
Liskov Substitution Principle：里氏替换原则
Interface Segregation Principle：接口隔离原则
Dependence Inversion Principle：依赖倒置原则
第二单元 电梯
电梯单元引入了多线程，而多线程的核心就是对共享资源的访问控制。这里我采取了最常用的生产者-消费者模式。本来尝试着将调度器也单独设置为一个线程的，可这样设计的复杂性就提高了，对线程安全的要求也更高了。所以，为了安全性考虑，也就只开了生产者线程和消费者线程2个线程。
本单元中，不同线程之间需要尽量降低耦合，追求代码简洁性的原意也是降低耦合。但如果过分注重简洁而忽略了代码的逻辑关系，有可能适得其反。
第三单元 规格化设计
第三单元接触了规格。本单元架构太简单，也没什么需要说的。
规格，其实就是契约式编程的产物。然而，需要注意的是，规格仅仅指定了一个函数应该达到什么样的效果，并没有指定具体的存储结构和实现方式，因此，在编写时，可以自主选择效率高的存储结构和算法达到效果。
第四单元 UML解析
本单元作业的规格设计显得比较简单，也许是经过了前面三个单元的训练后，我对于规格的掌握有了进步。总的来说，我认为本单元作业是对前期作业的总结。在面对一个特定的需求时，我可以将其划分模块，自顶向下进行设计。任何一个架构设计都不可能再一开始就具体入微。因此再确定了模块之后，我会针对每个模块在进行设计，然后再编码过程中修改设计，直到模块完成。
或许我对于架构的理解还不够深入，但我已经可以有意识的在动手编程前对任务进行拆分与分析。我想这学期的课程多少教会了我设计与学习设计架构的基本知识。
面向对象方法理解
最开始，我对面向对象的认知非常简单。我认为面向对象无非就是使用了一个类而已，原来C语言里属于全局的函数和变量现在属于某个类，其实并无太大区别，这也就导致了最初我的程序非常面向过程，代码维护起来难度非常大，经常需要重构。后来我才真正理解到，面向对象本质上就是为外部提供一个黑盒，外部无需关心这个黑盒里具体是怎样的，有哪些东西，只需要使用这个黑盒对外提供的少量接口就可以正确使用它。这可以实现代码的“高内聚，低耦合”原则，即一个类尽可能不去干涉其他类的实现，保证程序的可维护性。
总结自己在四个单元中测试理解与实践的演进
第一单元：这单元随机测试用的是python的sympy以及xeger库（利用正则表达式随机生成字符串），这单元作业需要保证程序的鲁棒性，因此数据设置的随机性要做的比较好，要尝试覆盖各种情况。
第二单元：电梯单元主要是随机测试，正确性检验主要是靠指导书的正确性判定规则书写python判定代码，投放数据是利用对课程组提供的jar包中添加定时输入进行改写。
第三单元：规格的出现让我对自动测试有了全新的认识。过去我在编写评测机的时候都是随机生成测试数据，通过工作量来保证程序的正确性。而JML则不同，他通过生成完备的测试集来进行测试。这样可以从理论上证明程序的正确性，但代价是需要更长的时间编写需求。而且对于大型程序，JML的表现并不好。在很多情况下，JML描述的规范并不能正确的被识别。因此，在测试时，我还是会首先选择随机生成样例或手写测试集。不过这个单元让我意识到，测试可以是证明，即用有限的测试去证明程序是正确度。
第四单元：这单元随机生成数据是不太可能了，即使随机生成，大多也是无意义的，因为查出来的结果大多是0或者异常。所以采取主动画UML图的方式，将自己能想到的各种情况分别画成UML图，再导出作为输入数据。
总而言之，原来我以为测试就是简单随机生成大量数据，然后与正确结果对比即可。但是，仅仅只有黑盒测试是不够的，还需要有白盒测试。白盒测试是需要在对程序的逻辑有一定了解的情况下进行的，如手动构造的测试数据和Junit测试工具。
黑盒测试的优点在于如果理论上测试次数无限大，是可以覆盖所有情况的，缺点在于测试次数不可能无限大，在有限的测试中难免会遗漏不少bug，并且这样做的效率也不太高。
白盒测试的优点在于对程序实现逻辑有了解，构造的测试数据会比较有针对性，缺点在于人的思维总是受局限的，很难一次把所有情况都考虑的尽善尽美。
从上面可以看出，白盒测试和黑盒测试是优缺点互补的。因此，我们需要结合使用。例如可以先进行大量黑盒测试，先找出一些bug，再结合这些bug改进自己的思考，然后进行白盒测试，有针对性的构造测试样例找bug，然后可以对某些细小的易错的方面又进行黑盒测试，如此往复。
总结自己的课程收获
OO课一大收获就是没有对象也可以自己new一个对象嘛（雾）。
在面向对象的学习中，收获最大的莫过于对代码迭代的认识了。以往写C语言的程序，题干是给定的，AC了就AC了，下一道题和上一道题毫无关系，因此无需关心程序的架构。但是在工程实际中这是不可能的，需求往往会经历各种各样的变化，因此拥有一个良好的架构，可以保证代码在迭代时尽可能的少重构，少修改。这会大大减少迭代的工作量，对于程序迭代更新是非常有效的。
面向对象所包含的内容有封装、优化、架构、测试等等，OO课对这些方面进行了深入的考察，对自己的工程能力有了质的提升。
立足于自己的体会给课程提三个具体改进建议
课程组已经做得很好了，但是一定要找缺点的话，可能以下三点是明年 OO 课可以改进的方向。
动态调整实验时长
实验有时候过于难，尤其是GC那次作业，阅读资料并深入理解就要花费不少时间，2个小时远远不够。有时候又过于简单，有可能半个小时就做完了。其实以后可以给实验设置动态的时间限制，不一定非得设置成2个小时，要根据这次实验的难度、内容的多少来确定。
尽量避免与面向对象无关的任务
我并不反对在面向对象中加入算法的内容，但是我认为可以降低其比重。在前两单元的作业中，优化的分数占到单次作业的20%，已经不只是学有余力的同学需要考虑的问题了。而且课程组的评分方法是以全体同学的均分为基准的，这就导致大家将注意力放在算法上，而非面向对象设计。比如，在第三单元的作业中，朴素的dijkstra算法铁定超时，必须采用堆优化的dijkstra算法才能AC，但同学并不能知道算法究竟优化到什么程度才能正确，这就会导致大家纷纷尽可能的往算法优化上面花海量的时间。虽然课程组本意并非如此，但在同学们的眼里OO课会变成算法课(2)，想必这也是一种本末倒置吧。
理论课与实验课脱节
理论课和实验课应当是一个互相促进的过程。我能感受到课程组尽力将理论课和实验课、作业联系起来。但是就我个人感觉而言，理论课的作用仍然不大，因为大家学了之后理论是懂了，但是具体怎么操作还得自己私下学习，相当于又把理论给重复学习了一遍，这样就会比较低效。建议理论课可以增加实验操作方面的小测，为实验打下基础。
谈一谈线上学习oo课程的体会
这是你从未体验过的全新玩法：线上学习。线上学习是在家进行的，相对于教室来说很安静，效果比较好。另外，理论课是录播，可以提前听完，同时有遗忘也可以快速找回。总的来说，游戏体验感良好。
我看到有的助教凌晨了还在改评测机，有的助教会不厌其烦的回答我的问题，甚至是有点白痴的问题。在此，感谢各位老师与助教的辛勤付出！你们让我们创造学习经历更加丰富多彩。
最后祝愿OO越来越好！