OO_Unit4总结&课程总结

本单元的作业是UML图的解析，作业的目的一是进一步强化架构设计能力，学会如何一步步将一个复杂的图结构进行多层解析。二是学习UML这一种强大的形式化语言，熟练掌握并应用到今后的程序设计与软件开发中。从难度上讲，本单元的难度相较于第三单元又有所回升，不过对时间复杂度的要求有降低。难度接近第一单元，但由于三次作业之间相互牵扯并不严重，因此一般情况下不需要进行代码重构。

1、本单元的架构设计

第一次作业

第一次作业的UML类图如下：

本次作业中，基本把UML类图的组件分成三层

• Class，Interface
• Operation
• Parameter

在调用主类的方法时想找到相应的查询元素，再逐层下降，从而调用低级类中的同名方法，查询到需要的结果。

这样的架构有一个潜在的问题是低级类无法查询高级类的属性（一般是表），因此设置了一个静态类，作为“总表”，一般装入id等索引，供低级类进行查询操作。

第二次作业

第二次作业的UML类图如下：

第二次作业针对顺序图和状态图，同样进行分层。

顺序图：

• Interaction
• Lifeline
• Message

状态图：

• StateMachine
• State
• Transition

同样是上层类不断查询到下层类去调用方法，下层类通过总表查询上层类的属性。

在本次作业中出现了一个类中方法过多导致超过500行的问题，因此强行拆类，将三个图的方法放在三个分别实现了相关接口的类中，并将这三个实例对象作为主类的属性，主类在调用方法时只需调用这几个分类的方法即可，节省了单个类的行数。

第三次作业

第三次作业的UML类图如下：

第三次作业加入了模型检验。由于我在前两次作业中，关于继承，实现等关系全部都在END_OF_MODEL后预处理完成，所有的查询指令只需直接查表。所以在这次作业中，我的这种写法需要改动的幅度就相对较少。只有R002需要额外新添方法，其余只需在已有的方法中进行判断并将错误类移入表内即可完成。

此次作业中错误信号的传递方向是由下层到上层的逆向传递，因此全部采用总表实现，模型检验类只需从总表中拉取数据即可。

2、四个单元中架构设计和OO理解方法演进

第一单元

在进行第一单元的时候，由于此前没有经历过这么大代码量的编程（计组个人觉得称不上编程），因此整个人完全没有架构意识和面向对象意识，还是处于一种写一行是一行的状态，整个三次作业下来的过程十分艰难。

第一单元对我来说最大的特色就是“重构，重构，再重构”。由于在编写代码时对增量开发考虑的不够多，因此每一次作业的架构都完全无法支撑下一次作业。当时一度对OO这门课感到绝望。

第二单元

第二单元着眼于多线程，是一个难度很高的单元，但我为了尽快培养自己的架构能力，于是顶着多线程的学习压力，不断思考自己应该进行怎么样的架构设计。相比于第一单元，第二单元的“面向对象”感更为强烈，各个线程之间的工作之间也更需要体现一个条理性，以及对线程安全的思考。

第二单元出现了一次史诗级大爆炸，强测中四个死锁让人猝不及防，最终还是采取暴力方式进行debug的。

我们至今仍未知道那天电梯死锁的原因。

第三单元

第三单元是JML约束编程，由于每个需要实现的方法都已经给予了限定的规格，因此这个单元可以说是在强行纠正学生的架构设计习惯，在本单元中，面向对象的思想体现的十分明显，每一个类调用其自身的方法协作工作，共同完成一个网络图的构建。

第四单元

第四单元也是类似图论的设计，这个单元虽然没有了那么严格的规格，但是我在写代码的过程中可以明显的感受到，前一单元中面向规格编程培养了我写代码的好习惯，无论多复杂的结构，我都可以进行很有条理的分层建构，规划实现。直到这时，我才感觉自己算是开始把握到OO这门课的脉络，开始理解一个面向对象的大型程序设计应该做成什么样。可以说，在这四个单元的不断学习中，我的架构设计能力与面向对象思维在不断的进步，这门课为我今后进行程序设计打下了不可替代的基础。

3、测试理解与实践

不同于计组全程在讨论区白嫖测评机和测试数据，在OO课中我在每一次作业都进行了测评机的搭建与测试数据的编写。由于高工的学习压力比较大，对于像我这样的程序小白来说，一个人折腾出一整套具有完整体系的评测机较为困难，因此，我们建了一个“小圈子”，几个同学在一起互相分工，搭建具有完整功能的测评机。

测评机主要分为三个部分，即驱动，数据以及评测。整个驱动部分基本完全由室友dl完成，从自动编译到运行，以及可能出现的多进程并发与TLE程序杀除，一条龙服务。只要把项目文件放在对应的文件夹中之后，其余工作都可以全自动的完成。（他还写了个邮件系统）

FJHNB！

数据生成在四个单元中略有不同。

第一单元的数据主要运用正则表达式进行生成，其中涉及到递归下降原理，第一次接触时可能较为困难，但理解之后会发现数据生成的代码量并不大。

第二单元的数据基本全随机实现即可（当然也可以针对性的构造较强数据），写起来较为简单。

第三单元的数据理论上也可以全随机（当然这会导致疯狂异常，整个数据下来没有几行有效的就是了）。另外一种方式就是在数据生成器中也构建网络图，这样可以地毯式排查所有可能的错误项。第三单元的数据基本全部由我完成，1400行的生成器化作死神的镰刀，只需要一个测试点便能将一个程序除性能问题以外的所有错误全部暴露。

第四单元的数据在实现原理上与第三单元类似，但相对更加复杂，不过如果不追求用一个测试点将有bug的代码hack的体无完肤（也很难吧应该），实现起来也不会特别困难，只要测试的测试点够多，一般的错误也可以被查出来，只是可能有点晚而已。

评测部分是对运行结果的检验。也许是巧合，前两个单元每个人的输出可能不一样，无法对拍，但直接检验结果正确性的程序相对简单。后两个单元若想直接检验结果，不亚于重新写一遍OO（还得保证不错），但由于每个人输出相同，通过对拍即可。

第一单元的正确性检验采用的是python中的sympy库，可以帮助实现求导。

第二单元的正确性检验采用的是状态机原理，针对电梯构建状态机，若落入异常状态则说明程序错误。

除了测评机搭建之外，还构造了相对极端的手动数据进行测试，也找到了一些bug。

4、课程收获

毫不夸张的说，OO是我上大学以来，我认为学过的所有课中最有用的一门，没有之一。

首先，这门课让我第一次接触较大型的程序设计，之前学习C语言和数据结构时，基本都是针对某一种算法写一个小的代码，这也是OO一开始感觉自己架构设计比较差的原因。但经过这门课之后，我今后再拿到一个较大的程序项目会知道从哪里入手，怎么去进行设计，这可以说是一个计算机系的学生质的飞跃。

其次，这门课让我学会了如何去对程序进行测试。搭建测评机即能帮助找到自己程序的bug，也能进一步的锻炼自己的代码能力。这种能力在今后的软件开发中也十分重要。

再者，OO课锻炼了我的协作能力，在整个课程的学习中，没有同学们的互相帮助，我们不可能在每次作业中都进行很好的测试。

5、三个改进建议

1. 在pre中可以新增一些内容，让同学们提前接触到多线程（最起码是了解）的内容，否则在第一单元结束后进入第二单元会非常，非常，非常痛苦。有必要的话开设前导课程。
2. 增开查看实验成绩的渠道。OO每次课上实验的内容都十分的有代表性，能增进我们的设计能力和对理论知识的理解，如果在进行完实验后能得知成绩的话，会得到更好的反馈效果。
3. 指导书在编写的时候可以更加注意一些语言上的细节，让同学们能够顺利理解，不产生歧义，这样也能减少讨论区中因为指导书文字问题而产生的过量时间消耗。

在这篇博客完成后，OO课程也就告一段落了。

12次作业，4篇博客，8次课上实验，1次研讨

我曾因为一个本地似乎永远也测不出，却连中测都过不了的bug寝食难安，用到了最后一次无代价提交机会才将测试通过。

我曾因为强测中突如其来的死锁而猝不及防，将自己的整个程序来回翻阅，去寻找可能的疑点。

我曾因为研讨课上因为一个不严谨的叙述被同学毫不留情的当面指出，万分尴尬。

我曾因为写代码时的疏忽，让提交的代码中出现了个人信息，幸好提前发现，万分焦急的去找助教解释才得以解决。

这门课给了我太多太多打击，让我摔了无数个跟头。

但我清楚地记得，每一次强测拿到满分时，内心的无比喜悦。

但我清楚地记得，每一次在找出自己的一个bug时，那种紧张和庆幸。

但我清楚地记得，在自己理解需求原理后，给身边同学讲解时的自豪。

我时常在想，这门课带给我的是什么？

学习一种新的语言？代码练习？还是更高的分数？

或许，更多的是一种跨越，让我从一个只会埋头写代码的小白，到一个能敢于去挑战软件设计的程序员的跨越。

“OO”，这两个圆圈，就好像一副望远镜，让我的视野更加宽阔，能看到更多从原来学习的课程中看不到的东西。

而这些东西，正是成为一个合格的程序开发者所必须的，或是基本能力，或是核心素养，或是在面对一些事物时展现出的心态。

或许在多年以后，我不再记得清楚这门课的内容，不再能说出我在作业中究竟写了些什么。

但我相信，这门课对我的改变，对我的塑造，是永远无法被抹去的，它会贯穿我的整个人生，并时时刻刻，默默发挥着作用。

那些曾在清晨，在傍晚，在宿舍，在图书馆，在课间，在课上完成的代码。

那些曾为了完成作业熬下的每一夜。

我们，

就此别过。