一、总结第四单元两次作业的架构设计

---

1.1 第一次作业

类图如下：

为了突出类、接口、方法、属性、和参数之间的层次结构关系，我为 Class 和 Interface 和 Operation 分别建立了三个专门的类来存储，Class 和 Interface 中包含下层的 Operation 和 Attribute ，Operation 中包含 Parameter 。（由于这一次针对接口的操作较少，应该有的一些操作被我注释掉了。）

本来调整过后将计算的模块都下沉到了具体的类操作，但仍有构造函数需要的一些操作没有进行处理，加上大部分操作都是关于Class，导致这两个相关类仍显得有些臃肿。

1.2 第二次作业

类图如下：

相较第一次作业，根据第二次作业的要求，我多建立了两个类，MyStateMachine 和 MyInteraction，类的详细内容如下：

主要操作仍然和上次一样，MyUmlGeneralInteraction 充当接口，具体计算下沉到MyStateMachine 和 MyInteraction 。

二、在四个单元中架构设计及OO方法理解的演进

---

2.1 第一单元

第一单元的作业是关于多项式求导的。

这是我第一次作业的类图，那时候刚开始学OO，写的代码除了符合 java 语法以外，纯粹就是C语言的结 构，想在尽量少的代码量下解决问题，却忽视了层次结构。

2.2 第二单元

第二单元的作业是电梯调度，要解决的问题主要是多线程中可能产生的冲突，是我认为最有趣的一个单元。

其中第三次作业的类图如下：

可以看出来，结构层次比第一单元的作业要清楚许多，各个类有各个类负责的功能，耦合没有第一次那么高了。（当然也是出于多线程安全的原因，不得不注意一些）

2.3 第三单元

第三单元的作业是关于 JML 语言的，前两次作业基本上都是关于图论，第三次作业具象化到地铁上了，

三次作业中架构的变化不大：

1. 第一次：完全按照官方接口建立。

其中 union 记录的是整个 container 中的不同的节点，每次 container 中的路径变化，更新一次 union。

2. 第二次：第二次作业将第一次中的 MyPathContainer 部分方法复制到 MyGraph 中，然后根据接口添加了 新的方法，其他大致都没变。

3. 第三次：这一次作业比上一次添加了很多要求，且复杂度更高了，并且涉及到一些算法上的问题。

我使用的是讨论区大佬的不拆点的算法，用四个数组分别记录、完成四种功能，但其实都是基于最短路径 的，只是每种功能中路径的权不同而已。每次更新 Path 时需要更新四个数组，且做四次floyd 。但因为常 数较小，所以时间相对较短。

2.4 第四单元

见 一、总结第四单元两次作业的架构设计 。

三、在四个单元中测试理解与实践的演进

---

3.1 第一单元

第一单元主要针对一些错误格式和特殊数据进行测试。我的主要测试手段是在写代码的过程中构造一些错误的、特殊的数据，这样在写的过程中能更注意相关结构，写完了也可以用来测试，在互测阶段更可以当作武器。

3.2 第二单元

第二单元主要针对多线程可能出现的同步互斥方面的错误，要对临界资源进行保护、加锁，或者避免出现同时访问的情况。由于多线程的 Bug 难以复现，难以针对性地构造数据。主要策略是进行重复多次测试，相信总有一次能命中。

对于可能的超时问题，其实对于每个调度算法都是难以避免的，后两次作业又禁止了写多个调度算法然后输出最优的方法，所以只能祈祷将自己的调度做好，保证测试完全不出现线程安全问题。

3.3 第三单元

第三单元的作业相较前两次其实简单了不少，因为给出了方法规格，找对好的算法，然后照写就行，不用太顾虑结构层次的问题。

测试方面我使用了官方推荐的 JUnit ，虽然仍需要自己构造数据，但测试的流程更简单明了，测试的覆盖度也可以做到更高。

3.4 第四单元

第四单元的测试数据依赖构造一个类图（状态图、时序图），自己生成然后测试的效率较低，所以主要使用小黄鸭测试法，对每一个指令的功能仔细检查，肉眼debug。

四、课程收获

• 了解了测试的重要性。有两次作业都是由于对自己程序测试不充分甚至根本没有进行测试造成强测翻车，有时候往往查下来是一个愚蠢的错误，只需要改一行就能解决的，成绩却差了几十分。

• 了解了面向对象编程的一些设计模式，如工厂模式、观察者模式等，虽然还没有机会付诸实践，但是了解了这些设计模式能帮助我在项目中读代码，能更好地理解别人的代码了。

• 对 Java 语言有了更深层次的理解。从一刚开始写什么都像C语言，到现在能运用一些 Java语言的特性来写代码，可以说是真正学习了一门语言。

五、 立足于自己的体会给课程提三个具体改进建议

• 希望BUG修复中，对强测的BUG修复后也能恢复强测失去的分。作为强测翻过车的人，能深刻的体会到BUG修复阶段的绝望，往往一个小Bug在强测中爆炸，三分之一甚至以上的分就没了。强测Bug应该加入互质Bug的计算，尽量减少扣分。

• 老师上课的内容可以更简单，更贴近作业内容一些。老师的课讲得很好，但课程的内容总是感觉是站在了整个课程策划、设计者的角度，没有站在一个老师的角度。作为一个学生，有时会感觉课程内容较深入，甚至有些无聊。

• 作业内容可以更缩减一些，或者占用时间减短一些。回顾这一个学期，大概有一半甚至以上的学习时间都用在了 OO 上。每次作业的安排、每周循环往复周一到周五Bug修复、周五到周二公测然后互测……这样的时间安排表在老师、助教，在训练者的眼里堪称完美，但作为一个学生、一个被训练者，这样的时间安排让我有些烦躁，全是OO。

最后，要感谢老师助教这一个学期的辛勤劳动。了解了这门课程往年的制度，才能发现老师和助教一直都在为课程的改进而努力。相信 OO 能越来越好。