第四单元实验博客

本单元作业构架

第一次作业

类图

复杂度

第二次作业

类图

复杂度

第三次作业

类图

复杂度

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

第一个单元

这个单元我对oo的理解比较基础，仅仅是把数据和代码放在一起而已，在第一次作业的时候，我的思路还局限于单项式可以是对象，运算必须是方法这个范围内，没有真正从“一切都是对象”的角度去思考，构架上比较复杂，每次作业重构也很多。一直到第三次作业，在指导书的提醒下，才把运算作为一个对象，完成了作业，但是之前留下的弊病比较多，所以强测结果不算好。这个时候，我并不理解oo的一些原则，只是基于朴素的逻辑思想建立继承关系。

第二个单元

这个单元是我第一次接触多线程，为了避免多线程安全问题，我在构架的设计上比较保守，基本上是照抄消费者-生产者模式，这样我避免了一些潜在的错误，也让我在优化算法上受到了限制。这个作业的继承关系是比较简单的，基本上就是不同的电梯之间继承。

第三单元

这个单元我开始接触规格，按照规格来编写代码，组织测试，使得程序设计更加简单。规格本身就已经包含了设计的构架，由于不需要思考具体的实现，我们可以把注意力从种种工程细节上抽取出来，专心考虑不同类之间的关系，但是需要注意的是，有了规格不等于可以按照规格写代码，相反，规格和实现并没有必然联系。

第四单元

这个单元开始接触uml图，不同的uml图从不同角度描画出一个程序的构架，我觉得uml图设计整体，规格规定具体细节，是oo程序设计的方向。

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

第一个单元

手动设计测试样例进行测试，基本上依靠本能，测试很不全面，难以发现问题。最重要的是，在构造测试样例时，思路会被编写的代码限制住，代码中会出现的错误，往往就是在构造测试样例时会下意识的回避掉，导致无法找到问题所在。

第二个单元

利用python随机生成测试样例进行测试，好处是测试样例具有随机性，不需要担心自己的思维漏洞，缺陷是随机样例不一定全面，有可能出现没有随机到的状况，另外测试脚本也不一定完善，有可能脚本本身有bug。多线程本身就存在bug难以复现的问题，有时候即使有bug，也不一定能测试出来。

第三单元

按照规格进行单元测试，对于每个方法都单独构造测试样例，有规格的情况下，基本能够实现比较完善的测试，但是对于复杂的方法仍然存在测试不够全面的问题。

第四单元

第四单元的测试思路和第三单元相似，都是根据要求进行单元测试，不过第四单元的测试需要对uml图有深入的理解，才能构造出完善的测试样例。

总结自己的课程收获

1. oo可能是我目前为止代码量最大的课程，计组结构是现成的，不需要自己设计，数据结构，操作系统都没有这么大的代码量，让我获得了很多经验，加深了对容器的理解，第一次编写了多线程程序。
2. 过去我进行程序设计没有一个基本的思路，从来都是想到哪里写到哪里，现在不同，我会先仔细阅读指导书，考虑大概会有什么样的测试样例，在考虑程序大概的构架，然后完善工程细节，我觉得，最好是先通过uml图设计构架在填充代码，不过我一般只是停留在脑内画图的层次。
3. 过去我的测试方案就是不测试，全部交给评测机处理，评测出问题来再说，评测不出就没有。现在我会根据要求构建测试样例，考虑问题比过去全面很多，也会编写简单的测试脚本，让评测手段更加多样化。

改进建议

1. 上机实验可以有bug反馈，让我们了解下标准答案
2. UML的知识很多时候需要靠课下自习。
3. 中测和强测差距太大，可以适当提升下中测，开放一些测试点。

网课感受

上课难以集中精力，幸好这门课以自学为主，否则必然会受到很大影响。经过了一个学期的锻炼，我在设计程序方面有了很大提升，感觉付出的时间是有回报的。