BUAA_2025_OO_U5

[李欣怡-23230601]

一、正向建模与开发

1. 仔细阅读指导书，明确需求。

可以看到，指导书对于结果正误的判定标准取决于请求是否被接受以及书籍的状态，因此如何处理各种请求是本次作业的核心。

2. 根据对请求输出的说明绘制草图

3. 参考草图和往届代码明确核心业务类，设计架构，绘制UML类图

由于草图中已经总结了请求是否接受的条件以及后果，我们可以把判断条件的方法和转移书籍的方法分装在相应的部门或用户类中。

4. 按照架构撰写代码，再根据修改随时调整UML类图。

二、架构设计

一个输入解析类MainClass，一个控制类Library，六个图书馆业务类，一个用户类User，两个辅助类Book和AppointedBook（主要是为了方便用容器统一管理各种信息）。

三、大模型辅助正向建模

即使运用了实验课给出的prompt格式（如ROSES），大模型提供的架构设计仍然不尽人意。无论提供什么指令，你都无法使得它提供的设计完全契合你的偏好。或者说，当你已经有了一定的想法时，大模型给出的解决方案只会更糟。也因此，我完全放弃了使用大模型进行架构设计，只是利用它查询一些编写代码时需要的信息。
而且，大模型有一些自己的陋习，比如没有MainClass类，容器喜欢选择Map、List，而不是HashMap、ArrayList。

四、架构设计思维的演进

• 在完全不理解面向对象思想的OOPre阶段，我在第一次作业使用了大模型生成了基本框架，然后在之后的迭代过程中进行增改。

• 在有了一定的个人理解之后，我觉得无法完全信赖大模型，但是单元作业的迭代需求又需要我前期有一个可靠而可拓展性强的架构，因此我选择去参考往届学长学姐的代码，然后pick出心仪的进行仿照。

• 而像本单元作业，因为业务情景很生活化，基本上就是用代码模拟现实生活中的图书馆，因此可以凭借感觉轻松分离出业务类和管理类，也就不用借助其他参考了。

  五、测试思维的演进

  1.OOPre阶段

  当时虽然要求编写Junit，但是主要是在应付差事，构造的样例很简单，覆盖率达标就够了。当时也觉得过了中测就是过了强测，对测试没太上心。

  2.为了Hack构造易错点

  进入OO正课，因为增加了互测环节，为了能hack到其他人会事先去准备一些指导书中或同届往届同学易错的样例，当然会事先在自己的程序上进行测试。

  3.Junit随机构造测试点

  有点简易版评测机的意思。在第三单元我发现测试可以和实现相分离，测试可以用一个复杂度高但不易出错的方法计算输出结果再与实现的结果相比较。而用随机数生成大量测试样例可以一定程度规避测试员的思维盲区。

  4.自己搭建评测机

  很羡慕，但自己还没有能力实现，要不之后课程出一个入门教程吧。

  六、课程收获

  虽然完成每单元作业耗费了大量时间，但我感觉很有意义，至少我从0开始自主搭建了一个可以实现特定功能的东西。这门课增强了我对编程的自信、锻炼了我面对惨淡强测成绩的抗压能力、使我更愿意与同窗交流心得和缓解了我的拖延症。我觉得我对Java这门语言理解和运用得更加熟练了，debug的水平也有很大提升，也学会了一些更好运用大模型辅助编程的小技巧。在学习的过程中，我觉得线下的理论课虽无“实用”但提供了抽象的上层思想，限时的单元作业磨练了我的编程水平，紧张刺激的互测环节使我更愿意去自行构造测试样例，隔周进行的实验课和讨论课则为我提供了其他人优秀的架构设计进行参考。总而言之，我觉得这门课程很有趣也很有价值，我期待后续的专业课也能保持这样高质量的水准。