BUAA_OO_U4单元总结

[刘展博-23371195]

一、本单元正向建模与开发

其实在本单元中，指导书已经将需要完成的工作描述得很清楚了，而且整个图书管理系统的机制与我们的实际生活十分接近，在理解层面也没有太大难度，只需要实现各个部门的功能即可。

1.第十三次作业

本次作业主要需要实现借书、还书、预约书、取书、查询借书记录以及图书馆内部整理等功能。根据指导书中的描述，我们需要先实现图书馆、预约处、书架、借还处、查询机、用户和书等类。然后，设计各个可持有书的类中存放书的容器、类与类之间交互的方法等。

这其中大部分方法的实现逻辑比较简单，但是在图书馆内部整理的过程中却有一些易错点。首先，如果我们自已研究图书馆内部整理的规则，会发现闭馆时整理图书和开馆时整理图书在逻辑上并没有任何的区别，只会使书籍移动路径的时间戳不同，然而这并不会影响正确性。因此，对于大部分整理工作，将其安排在闭馆时进行和开馆时进行都是可以的。但是，在本单元的大背景下，如果一整天都没有指令，当天就不会开馆，自然也不会闭馆。这就导致一些整理工作，如预约的书在预约处存放至第五天时恰逢当天没有开馆，如果把将其移回书架安排到闭馆时进行操作，该天就会跳过这一环节，从而导致在之后开馆时用户可以在预约处取到本来应该已经移回书架的书，产生逻辑错误。由于闭馆和开馆中间没有额外操作，而有操作的日期一定会先进行开馆，因此在目前已有指令的条件下，将所有整理工作都放在开馆时进行是最安全的。不过，整理工作的顺序不能安排得太过随意，比如预约处将逾期书移回书架应放在为用户预留书之前，从而尽量提高预留的成功率。

2.第十四次作业

本次作业相比第十三次作业主要增添了热门书架以及阅览室等机制。阅览的流程与借书是类似的，只是需要每天更新一份当日的热门书籍编号。不过，需要额外注意的是，读者可以选择在借阅书籍的当天不主动归还书籍，而是由借阅室在整理期间自动把遗留的书放回书架。这虽然对书籍本身没有什么影响，但是如果采取在读者主动归还书籍的时候移除读者“正在借阅“的标签，就还需在整理遗留书籍的同时把当天所有”正在借阅“的读者的该标签全部移除，防止读者再次借书时被拒绝。

当然，剩下就是一些避免热门与非热门书籍搞混的小细节了，理论上把所有将书籍放回书架的操作放在区分热门书籍之前就可以实现。

3.第十五次作业

本次作业主要增加了用户信誉分的机制，因此我们要在指导书的提示下全面设想需要加减信誉分的情境。在大多数情况下，信誉分是随一个动作的发生立即进行变动的，这里的处理相对较容易。然而，对于逾期的图书，其扣分的过程是一个连续的过程，每天都要发生变化，因此我们不妨将该环节放在开馆整理阶段进行处理，遍历图书馆内存放用户的容器内的所有用户，再遍历用户所有的持有书籍，判断其是否过期并设置flag区分是否为用户持有该书后第一次被判断为逾期。对于第一次逾期的书，按照逾期规则扣分即可，并记录本次扣分的时间；而对于不是第一次逾期的书，根据上一次扣分的日期进行扣分即可，同样需要更新扣分时间。

二、代码设计与UML模型设计

在本单元中，主要涉及到了UML的三种模型——类图、状态图、顺序图。与繁琐的代码相比，这些模型可以较为直观地反映出我们程序的逻辑。指导书中提到，不要等到代码完成后再对照其完成UML模型。的确，这样会使UML失去其意义。于是，我尝试通过构建简单的UML模型，帮助我对于更好地对整个程序有了初步的理解并勾勒出大致的轮廓。其中，理解了指导书中对于整个图书管理系统的规则与机制的描述，我们已经可以在脑中列出需要设计的类和一些必要的方法（当然这是对于并非十分复杂的系统，否则还需要在这一步仔细斟酌），然后我们就可以模拟实际的借书流程，设计简单的状态图与顺序图，这也相当于为整个程序搭了最基础的框架，之后考虑更具体的实现方式即可。

总而言之，面对一开始比较棘手的问题，我们可以借助UML模型逐步地理清自己的思路，搭建整个程序的框架，最后进行完善和细节的处理，这样可以使我们整个程序编写的过程按部就班地进行。

三、大模型的辅助

随着大模型的流行，我们在遇到困难时，可能会不由自主地向其求助，久而久之，也对其产生了一定的依赖。不过虽然遗憾，但也不失为一种幸运的是，OO这门课让我意识到，大模型远没有进化到能代替我们的程度。这不仅限于其会在一些简单的问题上不时地犯下愚蠢的错误，更在于其对巨量信息的处理能力、对于长文本内容理解的全面性、对于提问者需求解读的精准性决定了其并不总是能帮助我们解决遇到的越来越困难的问题。此时就需要我们自己对其进行由浅入深的层层引导。

其实在第三、四单元上机实验的内容中，指导书已经逐步教会我们如何引导大模型进行思考。主要是采取以下思路：首先，如果可以的话，先将问题完整喂给大模型，得出一份回答；然后，将自己对于问题的关键性理解以及更加细致的需求告诉大模型，让大模型重新生成一份回答；然后，让大模型针对自己的回答做出反思和检查，避免功能的遗漏，并和第一份回答进行比对，互相借鉴优点，最终得出一份更合适的答案。当然，在此基础上可以根据自己的需求不断让大模型进行微调，直至得出想要的结果。总而言之，要想让大模型得出令人满意的结果，提问者自身也是要对于问题有自己的思考与理解，并且能对大模型输出的结果有一定的分析与判断能力，找出其中的疏漏，因此，我们如今仍然不能完全依赖大模型，而是要借助大模型为我们完成一些不太重要、重复性的工作或者帮助我们打开一些新的思路，从而将重心转移到提升自己总结、理解、归纳问题的能力上，这会对我们的进步更有意义。

四、四个单元中的架构思维和测试思维

1.架构思维

经过四个单元的历练，我对于代码的架构也有了一些自己的体会。每个单元以迭代的形式呈现，其实在架构层面对我们提出了一定的要求，如果在完成前面的任务时只是蒙混过关，潦草地实现某些方法，那么迭代的过程可能就会变得有些艰难。在追求好的架构的时候，我们可以从容器的选择、算法的选择以及方法的实现等方面进行优化。比如第三单元中的并查集、动态维护、图遍历算法都在迭代或性能层面有一定的优化空间；第四单元中建立用户与书籍的关系时，是选择与书籍本身建立联系，还是与版本号、或是副本号建立联系，这也是值得我们仔细斟酌的。良好的架构，可以使我们编写代码的过程更有效率。

2.测试思维

要想确保自行编写的程序的可靠性，我们可以构造一些数据进行测试。此时，数据的强度就显得尤为重要，因为相比于大量的数据，有针对性的数据可以更好地帮助我们找到程序中的漏洞。至于如何发现针对性的数据，这就需要我们对于题目中的要求和陷阱了然于胸，构造能尽量全面地覆盖题目要求或充分考虑特殊情况的测试点。当然，如果有足够的能力，可以自行搭建评测机，通过大量数据检查程序的正确性。这就需要较强的代码能力，还要保证自动生成的数据有效，如第三单元中无意义的addPerson以及频繁会触发异常指令是需要尽可能地避免的。

五、课程收获

整体来说，面向对象这门课还是教会了我不少东西的。从第一单元的表达式解析及其中的递归下降思想、第二单元对于多线程工作的理解再到难度有所降低，但其实对我们的开发习惯、思考模式、大模型的使用以及与实际生活的结合等方面都有全面锻炼的后两个单元，都令我收获满满。唯一的遗憾就是前两个单元的学习中遇到了些许瓶颈，但我也在其中得到了一定的成长，有机会与身边的优秀同学们进行交流。回顾整个历程，面向对象带我一步步前行，给了我一个极其充实的学期，感谢OO！