OO第四单元总结&课程总结
OO第四单元总结&课程总结
- 第四单元架构分析
可以看到，基本的思路就是在MyUmlGeneralInteraction这个类中分别构造三个类用于处理类图，顺序图和状态图相关的指令。三个类分别根据自己要处理的数据针对性的构造数据结构。但这样仍然会导致两个问题：一个问题是要将所有的UML数据分别传入三个类并保存（没有甄别具体数据属于类图状态图或顺序图），使得空间的开销较大。另一个问题是由于类图实现的功能较多，在没有进一步封装的情况下显得十分臃肿（超过了700行）。
三种类中通用的数据结构是根据UML中parent关系构造的元素树（其中UmlAssociationEnd比较特别，其在reference而不是parent对应的数组中，这样可以大大地简化查询操作），通过HashMap存放某个UML元素下属的所有元素的数组。同时有一个HashMap可以通过元素的id找到对应的元素。
本单元的前两次作业相对来说比较简单，容易出错的点也不太多。
第三次作业增加了对于Uml规则的合法性判断，考虑到单独构建判断类可能需要重复传入数据，构造数据结构，因此我将对于各个规则的判断直接在对应的类中实现（这也是导致我的类图查询类超过500行的原因）。
本次作业较难的是对于各个规则的理解，在理解之后实际仍然是图论问题。其中比较复杂的是对于R002的判断，与上个单元判断强连通一样，需要用到Tarjan算法。
-
四个单元中架构设计、OO方法理解的演进
第一单元是我认为本学期最复杂的一个单元，同时也比较能体现面向对象的设计思想。前两次作业中我为多项式设计的类都只考虑了简单三角函数和指数函数，可扩展性很差，这也直接导致了第三次作业因子变复杂后我的程序完全没法修改，只能整个重构，最终强测也只得到了35分。同时第一单元还接触到了工厂模式。
第二单元是我认为OO课程中最能体现面向对象设计思想的一个单元，也是最有趣的一个单元。在第二单元刚开始时我就吸取了第一次单元的教训，考虑了可能的需求增加，因此最初设计的电梯类的可扩展性就比较好。同时在第二单元的设计中，还实现了各个类的职责独立，互不干扰。
第三单元主要是熟悉了JML这个设计工具，由于课程组已经帮我们做好了架构，因此只需要实现算法的封装就好了，相对简单。不过还是体会到了架构的重要性（好的架构能让写代码的过程变得很轻松，尽管阅读JML规格仍然很折磨人）。
第四单元的设计已经在上面提到，在此不再赘述。不过在第四单元的学习过程中我对于面向对象程序的设计和对象之间的交互有了更深刻的理解，不得不说在架构方面UML比JML要清楚直观得多。
- 四个单元中测试理解与实践的演进
从第一单元开始就有Dalao在评论区分享自动评测机的搭建心得，但我本人相对比较懒（也有实力不济的原因），就没有写自动化评测程序，基本都是手动构造极端数据进行测试，互测时也会在阅读同学代码发现bug后构造针对性的数据。
第二单元由于涉及到多线程，没法手动进行测试，因此使用程序进行数据的定时投放（然而数据仍然是手动构造）。
第三单元比较突出的是性能问题，但我也不清楚自己的电脑和评测机的性能究竟相差多少，因此也只是进行了正确性的简单检查。
第四单元由于需要数据的特殊性，我认为很难对数据进行自动化生成，因此采用手动画图导出数据的方法进行测试，同时与其他同学分享了一些测试数据。
经过一个学期的学习，一个感想就是：测试是对于好的架构的锦上添花。测试并不能发现所有的问题，同时就是测试发现了问题也可能需要重构才能解决，因此在写代码前做好架构的设计才是最重要的。
-
课程收获
首先自然是学会了面向对象的设计方法，通过各个对象之间的协作可以实现面向过程程序难以实现的功能。
此外还学会了使用git进行开发，模型化设计与验证等方法。
不过最重要的是养成了先进行架构设计再着手开发的习惯，同时在架构设计时锻炼了我的抽象思维，学会了从需求中抽象出对象及其对应的联系。
-
改进建议
-
希望实验结束后能够提供相应的反馈，让我们知道自己哪里有问题，并且可以思考改进的方法。
-
三四单元反复考察了图论相关的内容，重复性比较大，同时第三单元太过注重性能（即算法），对于面向对象的设计方法体现的并不明显。
-
研讨课的实际收益较小，导致很多同学不愿意听（有几次研讨课只有五六十人），希望以后研讨课能出现更多有价值的话题（不一定非要让同学进行分享）。
-
线上学习体会
线上学习相比线下学习更加灵活，并且视频可以反复观看，同时OO课并没有多少非线下不可的学习内容，因此我认为线上教学的方式非常适合OO这门课。如果非要说有哪些不足的话就是和同学，老师的交流比较困难，课堂讨论的积极性也不太高。
