BUAA OO 第四单元博客

钱龙骏-21371456 学生 2023-06-20 18:53:28

总结本单元所实践的正向建模与开发

本单元中，我实现了一个图书馆系统，该系统不仅能根据借阅命令实现对应的功能，还能模拟跨时间借阅情况，自动处理归还图书，购买图书，修复图书。

为了实现指导书中条目众多的需求，我主要设计了Controller和School两个类，School类下设了ArrangingLibrarian、BookerManager、BrLibrarian、LogisticsDivision、PurchasingDepartment、SelfServingMachine6个类，用于处理各处负责的事物。Controller作为带领用户办手续的引导员，将任务安排给各个部分。

下图是第三次作业的类图：

第一次作业

第一次作业主要建立了图书馆的框架，完成了UML类图的绘制。虽然指导书中推荐先使用uml进行类图设计再编写代码，然而由于我第一次接触uml，对于其设计不太了解，加之时间紧迫，我先完成了代码方面的任务，然后才基于代码绘制了um类图。

在实际实现过程中，管理员类内部经常需要使用Controller类内部的方法，出于方便角度考虑，我实现了Controller的单例模式。而对于同样需要共享的BookShell类，我并没有使用这一方法，这是考虑到之后的扩展任务可能会涉及到不同的BookShell。之后也确实如此，出现了校际借阅的情况，单一的书架不能满足条件，但是Controller依然可以用单例模式实现，将任务分配给不同学校的各类服务者类。

第二次作业

这次作业在第一次作业的基础上增加了【校际借阅】和【图书购入】两项任务。由于借阅过程的流程图较长，我在实现时不得不对第一次作业的内容进行大幅度的更改，并且新建立School类，将第一次作业中Controller类中大多数的方法置入School类中。当学生来借书时，Controller类对其请求进行解析，使用对应学校内的对应功能，完成请求任务。

这一部分的一大任务量是对代码中的方法进行重新整合。一开始我将时间部分的代码放在了ArrangingLibrarian类中，因为第一次作业中只有该类涉及了关于时间的操作。现在看来，这样的设计限制了代码的可扩展性。

这一部分另一大任务是理清任务执行顺序，确保任务处理不会出现冲突（特别是在一天结束时处理的任务和一天开始时出现的任务）。这一部分参考指导书中给出的顺序即可，但是设计时需要考虑输出顺序，避免依法连锁反应。对于一些难以判断的问题我找到同学进行了对拍，这对debug有很大的帮助。

第三次作业

这次作业代码方面的难度较低，增加了借阅期限的概念，相关部分需要着有关事件的部分处理，整体来说比较简单。淡然这次此次的中心主要在uml顺序图的绘制部分。

总结自己在四个单元中架构设计思维的演进

在架构设计上，我主要学习了如何提高代码的可扩展性，以实现三次作业的迭代任务。在架构起期间，要注意对于可能扩展的部分预留空间，减少迭代过程中无意义的工作量。另外，对于重要的方法要进行函数设计，保证复用。

每一次作业时，都要提前进行设计草图的绘制。绘制草图花费的时间要远远小于不绘制草图，直接版写代码走弯路花费的时间。这样也能尽早确定代码整体框架，保证自己对于代码主体有一个比较清晰的把握，这样在添加功能时才能快速找到目标位置。

总结自己在四个单元中测试思维的演进

测试部分我经历了手搓数据到随机数据再到嫖评测机的过程，这是和各个单元的任务要求息息相关的。头一个单元测试难度不大，或者说主要难度都集中在测试部分，通过仔细阅读说明能够很好地制造出较强的数据；在多线程这一关，通过助教给出的评测机，也能够实现手搓数据这一目标，可是想要监测出错误就很难了。这一部分我生成了许多随机数据进行测试，当然由于数据质量不高，测试效果不佳。

后续使用评测机的体验很好，虽然我自己没有写过评测机。通过评测机很容易找出代码中存在的bug，对症下药。特别是压力测试环节，能够发现许多非常细微的问题。