BUAA-OO-Unit4

这是北航2025OO课程的总结，希望能对你有所帮助😊

[!TIP]
针对第四单元的三次作业和2025OO课程全部内容，撰写技术博客
总结本单元所实践的正向建模与开发
总结本单元作业的架构设计，并对比分析最终的代码设计和UML模型设计之间的追踪关系
根据使用大模型辅助正向建模的体验，总结分析如何引导大模型在复杂场景中完成架构设计任务
总结自己在四个单元中架构设计思维的演进
总结自己在四个单元中测试思维的演进
总结自己的课程收获
注意：在编写完博客并发布在CSDN之后，请在对应作业处选择要作为作业提交的博客，点击提交。

结束了！

本单元的正向建模与开发

本单元的正向建模需要我们在具体写代码之前设计好架构，并由此画出类图，这需要我们在初始进行充分的思考，设计出一个相对灵活扩展性高的架构
但在具体实践过程中比较困难，因为很难在一开始就设计出比较好的架构，在实际写代码过程中还需要不断地修改完善

架构设计思维

除了Unit3，每单元的第一次作业都需要我们从0开始构建起一个基本的框架，这就需要我们在动手coding前必须要进行充分合理的设计，设计出一个友好的扩展性强的架构，以适应未来的迭代开发需求。
在我完成各单元架构设计的过程中，我一般采取”阅读指导书 > 分析理清需求与目标 > 阅读学长博客学习优秀架构 > 根据作业变化与要求设计出自己的架构 “这样的一套流程来完成单元架构的设计，既站在了“学长的肩膀上”，也有自己独特创新的设计

Unit1

Unit1的架构设计我主要参考的是第一次实验以及OOpre的最后一次代码作业，为了实现递归下降解析，我沿用了实验和作业的”lexer-parser”结构，自顶向下，从表达式到项再到因子；而为了将不同的因子统一起来，归一化处理，我使用了单项式-多项式的表征方式，将各种因子转化为多项式再化简。最终设计出”Lexer > Parser > Poly > Optimizer”的四维结构，实现文法解析到语法树解析，多项式转化到合并输出优化的流程，从而构建起来一个相对合理的递归下降与归一处理的代码架构

Unit2

Unit2我是基于实验代码和生产者-消费者模式搭建的，同时大胆合理地推测迭代需求，会从“指定电梯”演变为“自定义策略”，因此一开始设计架构就考虑了Dispatcher这一个当时看起来没有任何作用的类，同时也将电梯运行策略进行解耦，参考hyggge的博客学习并采用了LOOK算法，将输入、分派、决策、执行四个逻辑进行了解耦与分离。

Unit3

根据jml实现指定的类和方法即可，并不需要自己进行架构设计，主要关注点还是在性能、算法的优化上面

Unit4

第四单元我是直接根据指导书，然后自己构思了一下，将用户、书、书架、借还台等设计为单独的类，然后一点一点根据指导书和官方包完成自己的设计

测试思维

我的测试主要分为以下几个阶段
- 写完代码后用题面数据和自己捏造的数据进行最基本的测试
- 利用中测数据进行进一步的测试
- 利用评测机对程序进行更加全面的测试
这里主要说一说我的数据构造策略
纯随机生成或者略加限定的随机生成，生成的数据强度低，无法测试极限情况、边界情况，也无法对程序进行压力测试，检验程序的性能，因此我的数据生成会设定一定的逻辑。
根据不同单元的特点选择验证正确性的程序，比如Unit1可以借助现有的sympy库来进行化简比较，然后和同学对拍即可；Unit2的输出因人而异，无法对拍，因此需要自行设计验证程序来判断输出是否正确；Unit3的输出基本固定，可以直接和好友进行对拍。
为了便于修改数据参数（数据条数，各种常数限制等），我会选择将这些常数定义在文件的开头

Unit2

常规测试

我选择分组多次生成，每组生成8-12条请求，组内请求间隔随机在1s内，组间间隔随机在0.1 - 6s内
对于每一组数据，我设置了几种场景，通过指定不同的概率来随机选择场景进行生成
- high_concurrent：高并发，控制这一组的请求全部在同一时间投放
- high_concentration：高集中：所有请求来自同一楼层或者前往同一楼层
- high_burst：将5部电梯全部临时调度，然后生成其他请求
- random：随机选择请求
- multi_update：进行3次改造，然后生成其他请求

SCENARIO_PROBS = {
    'high_concurrent': 0.3,
    'high_concentration': 0.2,
    'high_burst': 0.15,
    'random': 0.2,
    'multi_update': 0.15
}

极端测试

针对高并发场景，我还设计了另外一个数据生成器，全部请求在同一时间或者间隔不超过2s内给出，以模拟真实场景下的高并发挑战
后来发现，强测数据中也有类似的专门针对高并发的测试点

并行测试

因为一次测试的时间往往在50s以上，甚至高达90s，所以单个case串行测试的效率极低，我们需要用多线程来测试我们的多线程程序
因为程序运行严格依赖datainput_student_win64，我是采用自动化流程建立十个子文件夹，然后启动十个线程分别在子文件夹下进行测试

Unit3

除了常规的有限制的随机数据外，我重点针对需要优化的地方设计了几种测试模式
special_qtvs：专门针对qtvs的生成模式。首先创建用户，接着建立所有其他人与1号人物的关系，并随机添加一些关系，然后全部加入1号人物的标签中，然后分2阶段测试，第一阶段在网络中随机修改关系，添加关系，小概率查询qtvs；第二阶段，添加了指令dft，以及增加了查询qtvs 的概率。
special_qba：专门针对qba的测试。首先建立一个总人数20%的核心用户群，然后在核心用户中每个用户随机添加2-3个关系，然后开始第二阶段，混合测试：40%概率执行qba查询，并且80%概率查询核心用户，20%概率查询其他用户；30%概率新增或修改核心用户与其他用户之间的关系；30%概率新增用户和关系值，
special_account：第一阶段：添加用户和关系；第二阶段：添加公众号，并添加一些关注和文章；第三阶段：海量的数据来随机进行以下几种操作：贡献文章、删除文章、添加关注、删除公众号、查询接受文章、查询最佳贡献者

Unit4

摆了，用的别人的评测机

辅助工具

大模型

在学习OO的过程中，可以结合大模型来辅助自己，比如我在Unit3中会将大段复杂晦涩的jml描述投喂给大模型，让其进行分析与解释，也会通过大模型来学习一些知识：比如并查集、双向BFS等
大模型对于明确的给定任务完成地相当出色，比如说：请你告诉我什么是Dijkstra算法并用java语言给出一个示例，这种任务大模型能够非常迅速地给出准确答案
大模型理解复杂业务需求的能力有限，比如你直接将作业指导书给它，那么它生成的程序会有很大的漏洞，但如果你是将一个类的jml描述给它，那么它生成的代码的正确性则会有较大的提升
当然，现在有很强的编程辅助智能体：cursor + claude4，编程能力疑似超越绝大部分程序猿，不过很多公司也不允许使用，其他的大模型也是不允许用的，原因之一在于保护业务的安全，防止数据泄露；另一方面，对于一些大型的代码，AI出手可能会适得其反

github

汇聚了全世界开发者的开源社区，里面能找到一些感兴趣的项目，以及学长的代码，甚至有评测机
维护好自己的github账号，可以将自己的代码和评测机也上传上去，实现开源与传承

课程收获

从当初OOpre课程对J面向对象一无所知到现在学习了解了许多新知识，比如：封装继承多态三大特性、递归下降、多线程编程、规格化设计、契约式编程等，一路走来，我既收获了知识，也享受这份学习的乐趣😁
抗压能力大幅提升，第二单元作业每周周五熬夜debug，第二次作业占据了我整个清明假期，第三次作业debug到了第二天早上5点，这些场景我终生难忘😀
学习OO的过程，我也结识了许多朋友与优秀的学长学姐，这种收获是无价之宝
一路走来，我也收获了对编程对开发的热爱，面向对象不仅仅是一种开发方式，更是一种思维方式，它将指导在编程的道路上继续奋勇前进，勇往直前！