OO第四单元总结

单元架构设计

本单元OO作业主要涉及两个过程，即先根据输入的elements数组建立UML存储模型，而后基于这个模型实现一系列查询判断功能。汲取上单元的经验，建模过程中模型数据容器的选择依据要求实现的查询判断功能而定，选择有利于加快查询判断速度的存储结构，总结归纳如下：

我所设计的建模算法只需对输入的elements数组进行一次遍历，速度较快。但所需解决的问题是，有些时候并不能根据输入的element确定UmlElement的类型，这时就需要诸多暂存的数据类型进行中间态存储（第一次作业中的Base即为UmlClass或UmlInterface的中间态，第二次作业中的Meta即为UmlEndpoint或UmlLifeline的中间态）。当出现能将中间态元素转化为确定的UmlElement的element时再将其“转正”。

这样的架构存在一定隐患，那就是在中间态元素“转正”时，其本身的属性自然容易拷贝，但指向它的指针却容易被遗忘，造成指针的失效。这个bug困扰我相当长的时间，而后通过维护一个指针Map解决。

【两次作业类图】

架构设计总结

第一单元的子任务是输入合法性检查和多项式模型的建立。合法性检查依赖正则表达式实现，多项式模型则由多项式的自然组分确定，分为项、因子、多项式等等。各部分的求导和输出依据各自特征进行。事实上，合法性判断也可以拆分到各个多项式组分中进行。

第二单元则是多线程架构的实践，掌握一些固定的多线程设计模式能有效保证线程安全、避免忙等。但由于时间紧张，我都是采取自己的简单理解以及强行加锁保证线程安全，牺牲了效率。

第三单元

第四单元

对OO的理解

在本课程的学习中，我并没有经历OO理解演进这样一个过程。从第一次作业起，我对OO的理解便是模块化设计。最强烈印证这个理解的是第一单元的最后一次作业——清晰地记得某天晚上想到逐级拆解的思路时十分激动，并迅速实现了代码。我认为OO包含模块设计及模块关系处理（接口）这两方面内容，这个理解似乎足以满足四次作业的设计要求。

测试演进

OO课程让我充分认识到完备测试之必要性，我的测试手段经历了如下演进：

脑海中随机生成数据（规律性极强，很难突破思维定式）

针对特殊情况（越界，个数为0等）构造测试集（无法稳定检测出结构问题）

手动构造尽量覆盖程序分支的测试集（分支较多时难以实现）

对于结果固定的程序，使用随机生成的数据对拍

课程收获

OO这门课让我对写代码有了全新的认识。写码前清晰的架构设计，写码时诸多细节的控制以及充分的测试对于一个工程来说都非常重要，缺一不可。另外，通过这门课我了解了面向对象这种强大的实现方式，其优势便是将巨大的project拆分为可解的部分实现，用这种breakdown的处理方式解决计算机问题往往非常有效。正如Butler Lampson所言：”All problems in computer science can be solved by another level of indirection.”

改进建议

由于一周时间十分紧张，往往不敢尝试固定的设计模式而自行摸索。建议课上内容增加对设计模式的讲解，或给出更为明确的参考资料。

建议给出自动测试的实现思路。