OO Unit4 总结
OO Unit4 总结
目录
1 第四单元作业设计
1.1 第一次作业
1.2 第二次作业
1.3 第三次作业
2 对面向对象的理解
2.1 抽象的思想
2.2 分层的思想
3 对测试的理解与实践
4 线上学习的体会
5 对课程的改进意见
1 第四单元作业设计
第四单元我们需要完成一个UML模型的解析器，需要我们对UML模型的结构有一定的了解，并且能够理解各个UML元素之间的关系。至于具体的算法，仍然与第三次作业类似，需要运用图论的方法。好在课程组已经为我们实现了文件解析、输入输出等很多功能，这使得我们实现起来不至于那么没有头绪。当然，阅读课程组的代码也花费了我不少的时间，但这也对我理解UML元素的结构很有帮助。
1.1 第一次作业
第一次作业中只需对类图进行解析。类图中有这样一些元素：类、接口、类或接口的属性、类或接口的方法、方法的参数、类之间的关联、关联的端点、类或接口之间的继承、类对接口的实现。其中有非常明显的对象，因此我在设计的时候几乎是按照这些元素去架构的。我为类、接口、属性、方法、参数分别设计了类，并在各自的属性中记录它们之间诸如包含、关联、继承、实现之类的关系。
实际上，这里已经可以看出这些数据有着图的性质，但我当时并没有按照这个思路去实现。此外，我设计了一个名为NameMap的数据结构，按照各对象的name组织，而按照对象的id去重。
1.2 第二次作业
第二次作业中加入了对顺序图和状态图的解析。与类图相同，顺序图和状态图都有着图的性质，需要进行的所有查询都可以用图论表示。因此，我决定重构之前的代码，统一用图论的语言描述。在类图中，类、接口、属性、方法和参数都是图中的节点，而包含、关联、继承、实现等关系都可以视为节点之间的边。按照不同的关系，可以将整个图划分成拥有不同含义的子图，查询时在各子图或它们的并中进行查询。
例如，包含关系构成的图是一个树林，其中类或方法是根节点，它们的子节点是属性或方法，而方法又以参数为子节点。当需要查询类的指定属性时，只需在该图中查询某个类节点的邻居节点，查找是否有指定的属性节点。又比如，当我们需要查询某个类所实现的所有接口时，我们需要用到继承、实现两种关系，因此先将这两个图求并，然后在这个大图查询指定的类节点可达的所有接口节点。
可惜的是，我并没有在指定时间内完成重构，所以就没有实现我的这一构想。
1.3 第三次作业
第三次作业中加入了对UML模型有效性的检查。实际上如果按照之前的思路，在图中进行查询，这是非常自然且容易实现的。然而，由于我的代码能力太差，没能完成有效的作业，对此我深感惭愧。
2 对面向对象的理解
这一学期，经过四个单元共十二次作业，我对面向对象的思想已经有了一定的理解，我认为这比编写代码、完成作业更使我受益匪浅。总结下来，我将自己的理解概括为两种思想——一是抽象的思想，二是分层的思想。
2.1 抽象的思想
抽象，我将其理解为从杂多的对象中抽取出共性的东西，并尽量将每个个体的对象表示为一些共性的组合。
以第一单元的函数求导为例。所有的函数（作业中需要处理的）都有着一些共性，比如它们都可以作加法、都可以作乘法、都可以求导。当然，有些性质并不是所有函数共有的，但却是一些函数共有的。比如多项式在求导运算下封闭，即多项式求导的结果仍是多项式，而三角函数也是如此。因此，在实现时可以在函数这个类下设计一个子类，表示所有在求导运算下封闭的函数，这个类的求导方法的返回值必定也是这个类的一个实例。如果继续这样进行抽象，就可以将我们需要讨论的问题拆分成很多个小性质，在分别实现了这些小性质之后，所有的对象都可以用它们的组合来容易地表示。
实际上，抽象的思想在很多的学科中都十分常见。在物理学中，就有质点这样的概念，实际上就是对各种实在物质的抽象。质点的概念将物质的概念中有质量、有速度、受力的作用等共性的性质抽取出来，而将其他性质，如有体积、有颜色、能导电等非共有的或是与所研究的问题无关的性质去除了。将这样的思想运用在程序设计中，可以将多个对象统一起来，成为一个个简单的结构，分别实现起来就更加容易。
2.2 分层的思想
分层，就是将复杂的结构划分成若干个层次，彼此之间仅有较弱的关系，可以分别处理。
JML就是一个很好的例子。JML的一个重要作用就是将开发过程中设计、实现、测试三个层次分离开来。顶层的设计者只需规定各个类的功能，并用JML描述其规格，而不用关心实现者如何实现各个类以及类中的方法；测试者只需要根据规格设计测试，使得实现的代码能够如规格所规定的那样运行，至于究竟要实现怎样的功能、以及如何实现，都不是测试者需要关心的；而底层的实现者只需要按照规格编写代码以通过测试，而不需要关心上层的架构。
分层的思想在各种工程中也非常常见，尤其在计算机硬件中，总是可以通过划分层次来处理非常复杂的问题、或是优化硬件的结构。从上面的例子也可以看出，分层的思想不单单是在科学技术方面有作用，在工作、生活的管理中也发挥着巨大的作用。
3 对测试的理解
OO这门课程再次提醒了我测试的重要性，并且教给了我许多测试的方法。
在第一单元中，我主要使用了随机自动测试的方法，这种方法的优点是可以自动地进行大量的测试，甚至可以批量对测试结果进行自动化的分析。然而自身的教训告诉我，这样的测试也存在着严重的缺陷。随机生成的测试样例大多数往往是同构的，一些极端的边界数据却经常无法覆盖，而恰恰是这些数据更容易引起程序的错误运行。
因为随机测试有着以上缺点，所以第二单元在随机自动测试的基础上，我又增加了手动构造的边界数据。然而这样凭借人工构造的数据，其覆盖率也并不高。此外，在这一单元，由于多线程的特殊性，我意识到了回归测试的重要性。在修复原有bug的同时，可能会引入新的bug，而多线程本就有着难以复现的性质，所以更应该用已经通过的测试样例再次进行回归测试，以防止引入新的bug、或由于随机运行而忽略一些bug。
第三单元学习了规格，从而接触了基于规格的单元测试。但我并没有真正地将单元测试运用到我自己测试的过程当中，其原因如下：首先，单元测试是建立在良好的架构基础上的。单元测试只能对某个类进行测试，而如果整个架构上有问题，是无法通过这种方式检测出来的；其次，对于某个单元来说，单元测试实质上也是自行构造样例，因此与普通测试无异。总的来说，单元测试是一种好的思想，但我个人并不那么喜欢它，因此并没有采取这种思想来进行测试。
在第四单元，老师向我们介绍了基于模型的测试，可惜我还没有来得及进行这方面的实践，也没有完全理解基于模型的测试到底提升在何处，因此不多讨论。
4 线上学习的体会
这学期由于特殊情况，我们不能在学校现场听课和实验，但实际上这并没有对我们学习这门课程造成影响。不仅如此，因为线上交流气氛比较轻松，我认为反而使得授课效果比现场更好了。尤其是课上的讨论和研讨课，大家可以更加大胆地发表自己的观点、提出自己的问题。我认为如果现场授课，反而可能会使有些同学（比如说我）因为紧张和胆怯而不发言。
但事情总是有两面，线上的实验体验就相对不那么好了。尤其是在提交阶段，或者是因为服务器的原因、或者是因为自己的网络环境不好，总是存在着各种问题。
总的来说，我认为线上学习的效果不但不比现场教学要差，更在某些方面优于现场课。在今后的学习中也可以适当地利用线上学习，取长补短，以求更高效、更积极的课堂。
5 对课程的改进意见
1. 希望理论课与作业和实验的关系更紧密些，我总是需要在理论课之外再查找很多资料、进行自学，才能完成作业和实验，不知是我自己的问题还是理论课的内容确实与作业有些脱节。
2. 希望对算法的要求稍低一些，算法的优化可以作为提高的要求，在强测中得到体现。请尽量让暴力算法能够通过中测。
3. 我认为线上的讨论可以保留，这可能会使得同学们比线下更加愿意去参与讨论。
