OO第四单元总结&课程总结

一、总述

随着OO第四单元结束，本学期的OO课程也已结束。在此撰文，对第四单元架构进行总结，并回顾本学期以来，个人从OO课程中获得的成长。

二、第四单元架构分析

（一）、UML图分析

第四单元任务是实现一个UML解析器，这要求我们对UML图有较好的认识。简单来讲，UML图中所涉及到的各类元素都被划归为某一种对象，各个对元素之间建立起父子、引用等关系。
总的来看，UML图将各个元素分类，这本身就内含了面向对象的思想，也很利于我们理解和进行编码；同时，各个对象间的关系类似于一张图，特别是若只考虑父子关系的话，还可以理解为森林。

（二）、个人架构分析

根据以上分析，图结构似乎是一个不错的选择。
但实际上，在本次作业的架构设计上，个人并未实现真正的图结构，而是主要采用建立特定映射的方法：利用HashMap等容器，对于有某一特定关系的对象间进行映射，这样不仅效率高，而且编码使用时直观方便。
例如，建立一个idToSubClasses的HashMap，即可给定一个UmlClass对象id，给出其所有子类。这种做法只要求我们提前预处理一遍所有需要考虑的关系，后续即可很好地调用。

同时，在我们构建架构时，还应注意每个元素的id和name之间的映射关系，既要利用id的唯一性完成映射，也要注意对不合规的重名name异常进行清查。
具体方法是对每一种需要查重的name种类（如className）建立两个HashMap，一个用于建立name到id的映射关系（不查重），另一个记录每个name出现的次数，使用时，先检查是否只出现一次，若是，则可直接取得对应id；若不是，则说明重名或不存在。

最后值得一提的是，具体实现API时，随着三次作业迭代开发任务量逐步增加，应该有意识地拆分任务，避免代码耦合过高、过于繁杂的问题。
在本架构中，最顶层是MyApi，实现了UserApi，提供给外界使用，其包含了MyUmlClassApi、MyUmlStateChartApi和MyCollaborationApi，这三个类分别实现了类图、状态图和协作图的API接口。
最后一次作业的合法性检测API也分别在对应的API类当中实现，再提供给MyApi调用。

以上，在本单元不涉及到复杂算法的情况下，便是笔者本单元所采取的架构设计模式。总体而言，这套模式具有较好的实用性与可扩展性，较好地完成了本单元任务。

三、OO课程全四个单元的历程

整个OO课程历经四个单元，带领我们从面向对象思想入门，到多线程，再到JML契约化编程入门，最后到UML，可以说是内容充实。下面简单总结回顾个人随着这四个单元的收获与成长。

（一）、对OO思想的理解与架构设计的方法

OO课程的首要任务，就是要理解OO思想，同时能够较好地运用这一思想。回顾整个OO课四个单元的历程，从对面向对象懵懂无知，到现在能够较好地按照任务要求，利用面向对象思想，设计出较为合理的架构，确实学到了很多。下面随各次作业历程分析。

1、第一单元——面向对象思想奠基

第一单元要求实现一个多项式化简程序。如果不利用面向对象的思想，很难做到之后的迭代开发。
总的来说，第一单元让我体会到了面向对象思想的独到之处，其通过数据与方法的封装，配合以类之间的继承、关联等关系，让程序员能够有效地组织其整个程序的架构。

2、第二单元——多线程及架构设计入门

在第一单元基本熟悉了OO思想后，第二单元在多线程编程上提出了新的挑战，而这也正是对于架构设计的挑战。
在这一单元中，由于多线程的存在，使得增量开发更具挑战，一个需求的增加往往难以在一个线程中单独实现，需要多个线程以及共享对象的相互协作，这就要求我们有更加宏观统筹的视角来筹划我们的程序架构。个人认为，清晰划分线程功能，明确共享对象状态以及确定线程工作流程，是架构层次化设计的关键。
通过这一单元的学习，让我深刻认识到了架构设计的重要性，并在实践中不断积累经验，有了基本的架构设计能力，同时入门了多线程。

3、第三单元——契约化编程：带着镣铐的舞蹈

经过前两个单元的锻炼，第三单元从实际工程的角度向我们介绍了以JML为代表的契约化编程思想。
总的来说，契约化编程通过利用逻辑来抽象化、规范化代码的编写过程，能够帮助我们省下很多精力。但我们也不能照搬着JML进行CRUD，为了更好地完成任务，满足规定的性能要求，我们必须充分利用JML规格，带着镣铐起舞，因此，本单元也是对我们算法编程水平的一个考验。
这一单元是我在架构设计思想等方面的一次提升，让我能够从更加开阔严谨的角度审视自己的编码过程。

4、第四单元——UML设计

第四单元在本文开始已经谈及。
除了单纯的学习UML相关知识外，其算是OO思想与架构设计训练的一次良好结合：UML自身元素即是面向对象特性的体现，同时元素间的关系在作业中也是架构设计的关键。

5、总结

至此，个人认为自己对整个OO的思想和架构设计已算是初有心得。OO通过封装数据与方法、明确类之间的关系，让架构变得清晰，但架构是否合理，还得取决于程序员设计的水平，我们利用OO这一工具，结合实际的需要，在JML和UML等工具的帮助下，设计搭建起自己心中能work的架构，这即是最终的目标。

（二）、测试方面

测试是程序编写最为重要的环析的方法上更进一步，特别是从第三单元接触契约化编程以来，通过划分有效集，针对其划分的不同情况构造特定样例，以保证每一段代码的完整性与正确性。可以说，第三和第四单元的测试相比过往更具目标性和科学性。

四、课程收获

上文已经从很多个方面说到了个人在本课程中的收获，包括OO的思想、架构设计能力以及测试和DEBUG能力。若从更宏观的视角来看，OO课带给我最大的收获便是增强了一个代码编写者的基本素养。
在上OO课之前，写过的代码不算少，其中有涉及到复杂算法的，也有涉及到实际小项目的，但总让我感觉有所缺失，经过OO课的磨练，小小地补全了这一种缺失：那就是面对实际工程应用时，如何从思想出发，运用合理的设计模式等经验，搭建起实际有效、扩展性良好甚至性能优异的架构，同时保证整个程序的正确性和健壮性。
当然，我并不是说学了OO课，对于这些问题就能手到擒来，甚至可以说我在OO课上费尽心思不断修改出来的程序最终也只是个玩具——但这个玩具的制造过程却让我真切的体验了一个面向实际工程的软件是如何被编写的：从UML的设计，到JML引导的协作开发，再到多线程间的交互，最后具体到OO思想抽象出来的一个个设计精巧、关系紧密的类。可以说，OO课以面向对象做引子，让我更加深入的学习了解了“软件开发”这一凝结了无数人心血的工程。
或许我离一个真正合格的程序编写者还很远，但我相信我已进了一步。

五、对课程的建议

1、加强研讨课小组分享的引导，更加具体一点，不然现在给的话题太宽了，讨论时没有针对性，都敷衍说一些表面的东西。
2、将多线程简单加入到Pre中。对于没有多线程编程经验的同学来说，第二单元一上来确实有点不容易。
3、加强对设计模式的指导和引导，可以考虑作为一个强制内容，逼迫同学们用一些设计模式。节之一，其决定了一个软件能否面对真实的世界。在OO课程中，课程组和互测的同学们为我们提供了很好的软件测试环节，虽然这有时会让人感到痛苦。
总的来说，就个人对软件的测试来讲，通过课程还是收获许多。
第一单元主要采取的方法是大规模随机样例检测，这样做虽然稍显笨拙，但有时可能会很有效；同时还会搭配压力测试，取一些极端的数据。这两种方式算是“传家宝”，在之后也一直被使用。
从第二单元开始，静态代码检测的测试方法开始被重视，这主要是由于多线程特性造成的。事实证明，这是一种值得重视的测试方法，更有针对性，在状态好的情况下更有效率。
第三和第四单元过后，在静态代码分