OOpre总结反思

林之吟-24373035 2025-11-07 11:58:54

OOpre总结反思

一、架构设计及迭代中的架构调整

作业最终的架构设计

迭代中的架构调整及考虑

take bottle 操作实现方式修改

一开始将take bottle操作作为 bottle 的一个属性处理，即在 bottle 里面添加 iftake 属性
后来选择在 Adv 里面添加 bottletakes 列表，通过列表删改表示 bottle 的携带与放下
调整原因及考虑：
在后面的作业中添加了新限制 “冒险者只能携带 10 个药水瓶。当冒险者药水背包容量满时，再携带药水时，会顶替掉当前携带的药水瓶中最先携带的一瓶（变为未携带状态）”
使用列表更方便判断背包中携带的药水瓶数量，即 bottletakes.size() ，同时可以直接通过 bottletakes.remove(0) 和 bottletakes.add(bottle) 实现顶替最先携带的操作

指令处理模块以及 Advlist 位置调整

一开始把指令处理模块以及 Advlist 直接放在main类中
后来选择把这些功能移动到 AdvService 模块
调整原因及考虑：
将指令处理模块及 Advlist 从 main 类中迁移至 AdvService 模块，主要是为了遵循单一职责原则，避免 main 类承担过多功能，导致代码臃肿、难以维护。
功能集中在一个类中会增加测试复杂度，难以进行单元测试和模拟。通过分离至 AdvService，可以更清晰地划分职责，便于编写测试用例，提升代码质量和可测试性。

二、使用JUnit的心得体会

优点

JUnit 能够帮助我独立检查各个功能的正确性
在迭代过程在完成新功能后，JUnit 帮助我简单判断功能是否成功添加以及运行，同时通过运行已有的测试集，可以快速判断新代码是否破坏了原有功能。
JUnit 偶尔也能帮助我发现写代码的时候某些逻辑错误，比如我在下级援助上级的时候没有判断法术类型，可能会使用攻击法术“援助”上级，我在写 JUnit 就发现了。

不足之处

目前我对 JUnit 的使用仍存在一些不足之处：
我目前使用 JUnit 只能判断功能的简单实现，由于无法构思出全方位的测试样例，使用 JUnit 一般无法帮我 debug。
我编写的测试用例多集中于正常执行流程，对于一些边界条件（如背包已满、属性为0、输入格式极端情况）和异常分支的覆盖不足。
有时测试代码会与具体实现细节紧密绑定，导致一旦修改内部逻辑（如改变一个容器的类型），即使外部行为不变，也需要同步修改大量测试代码，维护成本高。

三、学习OOPre的心得体会

在此之前，我习惯于使用C语言进行程序设计，编写的多是功能相对简单且无需迭代开发的代码。于是，我习惯将所有功能堆砌在一个.c文件中，大部分逻辑都直接写在main函数里，导致代码重复率高、模块界限模糊。
通过OOpre课程的学习，我深刻体会到了面向对象编程范式的优势。课程中的多次迭代开发让我认识到，将功能合理地抽象为具有独立职责的类，不仅大幅提升了代码的可读性和可维护性，更使得后续的功能扩展与修改变得高效而安全。这种从“面向过程”到“面向对象”的思维转变，让我学会了以封装、继承和多态的视角来构建更加健壮、灵活的软件架构。
面对需求的变化（如药水携带数量的限制），一个好的面向对象架构展现了强大的适应性。通过前期合理的抽象，新功能的加入往往只需要在局部进行修改，而不会引发整个系统的重构，这让我深刻理解了软件“可持续演化”的重要性。
通过课程对Checkstyle代码规范的严格要求，我认识到工程化开发中代码风格统一的重要性。在以往的C语言实践中，我编写的代码更多的是“写给自己看”。而在OOpre中，我开始有意识地遵守命名规范、编写清晰的注释、配置Checkstyle插件进行实时检查，以此保证代码风格的一致性。我认识到一个结构清晰、文档完备的面向对象系统，能够极大地降低团队成员之间的沟通成本，使得代码交接和协同开发成为可能。