2024BUAA-OO-UNIT4总结

正向建模与开发
正如荣文戈老师所说，一个熟练的或者说优秀的程序员，写出来的自然就是好程序，面对未来潜在的需求具有扩展性。然而像我这样的同学，虽然在这几次作业中都尽量按照课程组推荐的“先设计再实现”的方式完成作业，但是事实证明并不具有那样一开始就能够设计出完美程序的水平。甚至往往第一版的设计在实现过程中发现都无法完成本次作业的要求。
在这几次作业的迭代中，我先前的一些考虑以及设计都有些不过合理。让我们依照hw13的类图来解释说明：

不符合迭代的设计有：

1. 构造的MessageList类，
   本意是让每个message对应一种书籍的移动，使用MessageList应对多线程的场景，在第一次作业中其实并没有使用MessageList，之后也没有用到，直接删除了。 而Message中其实也只使用到了两个MessageTag。在hw14中将Message添加了 pass 方法，用于方便的构建新的Message用于传递。这个方法理应存在，这也体现到了hw13中架构的不完全。
2. 额外构建了自己的一些异常类，
   然而事实上并没有什么应用。底层throw出来的异常最终都会被ignore掉，而事实上正常的输入并不会触发这些异常，也对debug没有帮助。
3. 对书籍的管理，构造了BookList类并采用单例模式。
   这样设计的考虑在于当同一本书的数量很多的时候，如果全部用book类存储，将会占用很大的一部分内存空间。于是只在booklist中存储一份书籍，并且对不同的书籍管理者直接赋予一份数组用于表示书的数量。对于如何在booklsit中快速查询书籍的数量也有一些设计。但是后边的迭代会加入新书籍，这部分的优化就变得繁琐，最后回归了直接查找。单例模式booklist的最大问题在于可能具有“多个书架”。如后续迭代中的漂流角设计。漂流角对正常书籍的借还没有影响，但是理应和正式书籍共用一个借还处。这使得借还处无法继承使用Booklist存储的BookContainter类，最后重构了借还处设计，使用Message的List存储借还需求。

不过，还是有些设计最后发现有其可取之处。例如Message的构造使得hw14的一些重构过程变得十分方便。虽然有占用过多空间的嫌疑，不过最初的Message设计除了保存官方包request的所有信息以外，还会存储时间、book在流程中位置的枚举信息。并且能够方便的完成续借需求。student和studentList的抽象也十分成功。

总之本单元的作业最终还是相当于先实现再绘制图表。因为第一次图的设计基本上全部被推翻修改。最后在实现完成之后再次修改绘制图表。

架构设计思维的演进

最开始，对于面向对象课程最大的疑惑就是为何只讲思维、架构，而不讲具体的实现方法、算法。后面才发现面向对象有很多种不同的设计实现方式，都是正确的。具体选择哪种是不同程序员的区别。
第二单元的多线程，是以后做程序工作的主要内容。主要学习了同步互斥的概念，也是第一次接触多线程程序的设计。
第三单元jml主要在于对高要求程序设计的工作流程学习，主要考虑在“读懂”jml，感知上似乎并没有太多的操作空间。
最后是uml，也就是注重设计能力。对于图评测也就是避免同学们仅仅画图应付工作。
经过几个单元的学习，架构设计思维会从原先设计几种对象，然后从面向过程的考虑来写代码。流程中多个文件和类的代码互相交错书写，最终直到完成整个目标。渐渐也熟悉了面向对象的工作流程，编写代码也是先把一个文件一个类的代码全部写完，一个类一个类的编写，有不妥的地方再修改，是更加符合面向对象思维的编写模式，其实也浅浅暗含“先设计再实现”的方法。

测试思维的演进

最开始，我个人是比较推崇构造数据测试的（这种测试做的好的话肯定是可靠的，比如课程组不就是这样评分吗）。之后接触了junit单元测试，我认为这种测试在重构中用处较大，而比较难以从覆盖率什么的判断出代码的错误。不过jml的学习让我对junit测试有了额外的认识：junit除了一个一个方法的类测试，也可以单纯从另外的角度构造整体测试，而且检测的范围比黑箱测试更大更灵活。不过，在书写和使用了一些自动生成数据的评测机、junit方法之后，对于自动生成数据的可靠性有了理解。这种生成数据的测试，也需要细心的设计数据范围，才能达到比较好的效果。不然单纯靠压力测试，即使找到了bug也很难定位bug的位置并及时修复。

课程学习的收获

虽然经常吐槽java平时作业的压力大，吐槽java纯靠自学。不过在自学中也确实收获了很多。可以说课程组的设置还是比较聪明合理的。通过这门课可以说真正能够入门面向对象程序设计，熟悉整个开发的流程，并且不忘记代码规范，并且自行写出一些具有一定规模的程序。最后，荣老师的java课上也让我学习到了很多C语言的知识，面向对象真的是海纳百川呢。