时间过得很快，仿佛昨天还在学习java那有些陌生的语法，而一转眼，就要和OO课告别了，以下是本人这学期OO所学内容的一些个人体会和新得。
一、Unit4架构设计
Unit4中我们主要学习了UML图这个内容，UML图与代码的设计关系是十分紧密的，所以我们要回去掌握这种技能。而掌握一种新知识的好方法就是去实际接触，于是，本单元的作业围绕着解析各种UML图为中心内容来展开。下面浅谈一下本人在三次作业中的架构设计。
HW1
HW1我们只需要解析UML类图这一种图，并从中获取各类所需的信息。故很自然地想到专门开一个MyUmlTree类来存储输入的信息并分类。架构的UML图如下：
当MyUmlInteraction要查询各类信息时，直接调用MyUmlTree的相关方法即可。
HW2&HW3
因为HW3只是在HW2的基础上添加了一些检查错误的方法，并未添加新的元素解析要求，所以本人这两次作业的架构是一致的，这里放在一起来讲。架构的UML图如下：
HW2和HW3的架构是顺着HW1的思想修改而来，因为作业中我们要解析三种图，每种图的元素之间的关系差别较大，因此用三个类来分别存储不同种图中的信息。初始化时，由一个分类器类MyUmlTree类进行分类并对上述三个类初始化。调用查询方法时，根据所需查询的图的类别来调用相应类的方法。
总的来说，个人感觉自己Unit4中的架构设计还是有点过于简单粗暴了，并未过多地考虑到相应的性能问题和可扩展性，还是要感谢课程组在最后的一单元有意降低难度的体贴之举。
二、课程架构设计及OO方法理解的演进
这学期的学习，对于我来说，就是一个不断加深对OO的理解的过程。
Unit1的HW1时，我还停留在之前学习C语言做作业的思路，傻傻地以为每次作业是相对独立的，傻傻地以为只要完成功能就ok了，而没有去考虑代码架构。虽然我顺利地完成了第一次作业，却也成功地在HW2时迎来了我人生中重构代码的开始。整个Unit1我一直未设计出一个逻辑清晰的架构，因为我一直将计算多项式和化简多项式两个步骤杂糅在了一起。而架构的失败导致了我码代码的事倍功半以及bug的频发。
Unit1的经历是惨痛的，但教训换来的是我个人的迅速成长。Unit1结束后，我仔细地研究了课程组的推荐代码以及个人代码中的不足之处，总结了一些面向对象的重要方法，比如“分而治之”、“工厂模式”等等。
到了Unit2，我们开启了多线程的学习。多线程自带的复杂性，要求我们要更加重视编码前的架构设计。这个单元，我们又学习了很多设计模式，比如生产者消费者模式等。这些模式相当于是前人代码架构设计经验的总结，学习这些精华，让我在架构设计上更进步了一层。体现在这个单元的作业上，就是我的架构已经具备了一定的可扩展性，三次作业基本核心架构没有大的改动，并且我完成作业的效率和正确率都有了显著改善。
而Unit3和Unit4的学习，虽然并未直接教授架构设计相关的知识，但我却在实践中进一步得到了经验教训。Unit3主要围绕着JMl规格去撰写代码，然而，我却又一次犯了老毛病，仅仅着眼于实现规格而忘了代码的架构设计。这个错误带来的，是我整个Unit3的性能爆炸。深刻的教训让我更加意识到，代码架构设计永远是第一要点，永远不要因为一些较为明确的任务目标而忽视架构设计这个隐藏的首要任务。最后的Unit4，我在完成解析UML图这一基础任务上，铭记了上一单元的教训，实现了一个简单清晰的架构，顺利地完成了整个单元。
要而论之，本人的架构设计及OO方法理解的演进是一个不断犯错，不断总结，不断改正的过程。从接触到学习再到实践，这就是本人的OO架构之旅。
三、测试理解与实践的演进
测试一直是编程必不可少的一个重要环节，这点也是我在OO课上学到的教训之一。
测试1.0时代——人工测试
在学习Unit1的时候，讨论区就已经有了关于自动化测试的讨论。可惜那时本人年轻不懂事，傻傻的以为自动化测试由于其随机性而并不能做到很强的测试(当然不会说主要原因是因为自己懒），沉迷于自己手捏极端数据。这个脑残举动的后果就是Unit1的强测爆炸。于是Unit2，我开始学习自动评测机的构建。
测试2.0时代——自动测试
不得不说自动测试还是非常强大的，一定程度上甚至可以做到强测的模拟。Unit2多线程电梯的测试本人造了一个比较简陋的自动评测机，虽然每次hack时都会发现评测机本身有些小小的bug，但还是靠着很好的测试强度保证了自身代码的正确性。
测试3.0时代——Junit测试
其实，Junit测试似乎在第三单元之前课程组就有些铺垫，而我又一次犯懒，到了第三单元的HW3时才开始使用这种测试。这种单元测试可以对代码的每个模块进行检验，相比于一般的printf大法，其可以快速锁定bug区域，不失为一个更优的选择。
测试4.0时代——白嫖测试
与其说是4.0时代，Unit4的测试更像是0.0时代，因为我本人几乎并没有造任何数据，几乎一直靠着他人的测试样例来进行debug（自信点把几乎去掉）。这种做法是非常非常非常不可取的！！！但我在这里还是要感谢一下每次施舍我很给力测试数据的同学们。
在我看来，测试固然是十分重要的一个环节，但我以为，我们更应该做的是不去犯错而不是犯错后如何检查。写代码最重要的，是有一个良好的架构作为基础，以在设计层面就最小化出bug的风险，而编码之后的测试，自然是锦上添花之举。
四、OO课程收获
本门课程的收获对我来说真的太多太多。一学期的OO课程中，我认识了一群很优秀的老师和助教，学习了一门新的编程语言java，掌握了starUML等工具的使用……但其中最大的收获，莫过于思想层面上的收获了。
OO全称是面向对象构造与设计，我以为这门课程的中心就在于构造与设计五字之上，脑中没有这五个字是万万不行的。前面已经说了很多有关代码设计上的感受，但其实，在这里我还想说的是，这中构造与设计思想其实是超越代码，走入生活的。生活中需要你去策划的场景是很多的，这个时候，就像完成OO作业一样，你需要在着手之前去设计好整个任务的完成步骤，此时”分而治之“、”高内聚低耦合“等OO课程中的思想就能得到应用。
也许若干年后我会忘记JML是啥东西，会忘记代码风格检查，甚至会忘记java这门语言，但我相信，这门课程中所学习的思想永远是刻在我脑海最深处的东西，他们会在以后的生活中不知不觉地帮到我。感谢课程组这一路来的悉心教导，让我能得到这一笔宝贵的财富。
五、课程的改进建议
-
稍稍提高一下弱测的强度
虽然能理解到课程组把弱测设置成很弱的用心，但各别作业中的弱测甚至都没能将待实现的功能测完，我认为这是不太友好且没有必要的。希望以后的弱测和中测部分最少要保证将每个功能都进行测试。
-
改进一下研讨课的形式
可能是由于线上的原因，个人感觉这学期的研讨课未进行展示的同学参与度不高。个人建议以后的研讨课可以改为小组的形式，每次展示后每个小组进行讨论并派代表提出本组的问题或看法。这样能使更多的同学参与进来。
-
Unit3的优化
个人感觉第三单元的作业和测试形式有点过于单一，基本就相当于考察算法能力。除此之外，第三单元博客作业中要求的一些关于JML的工具链的功能也不是十分完善。因此，我认为第三单元的JML作业应当优化，可以增加多种形式，比如自己撰写JML等，而不只是去按照JML完成代码，然后拼命优化算法。
六、线上学习oo课程的体会
其实个人感觉计算机课程的专业课因线上学习受到的影响是最少的，因为实验和作业本来就都是线上展开的。但就我个人来说，在家学习还是使我的学习效率有很明显的降低。体现在OO上就是较差的作业质量和较少的测试程序。总的来说，这个学期对在家就变得十分懒的本人真的是十分艰难的，不过相信对于课程组的老师和助教们来说，线上的教学也不是一件易事，所以还是要再次感谢课程组的辛勤付出与陪伴。虽然线上学习某种程度上可能让我的成绩打了折扣，但更多的挫折带给我的，是更多关于设计与编程方面的经验教训，塞翁失马，