2025 OOPre课程总结

[黄家宝-74066213]

一、最终架构设计与迭代思路

我整个项目的结构大概可以分成三条主线：物品系统、魔法系统、以及主体逻辑模块。下面这张类图就是我最后整理出来的架构。

1. 物品系统（Item → Equipment / Bottle）

最早写的时候，我所有物品的逻辑都放在 Adventurer 里，越写越乱。后来发现其实物品本身更适合抽象成类，所以就把 Item 作为最顶层父类，然后按功能分成了：

• Equipment（武器 / 护甲）
• Bottle（四种药水：Hp、Mana、Atk、Def）

像 Bottle 这一块，一开始我只有一个 Bottle 类，效果写成 if-else，后来测试越来越多，我把不同属性的药水拆成四个类，逻辑就清晰很多，也更符合“一个类做一件事”。

2. 魔法系统（Spell → AttackSpell / HealSpell）

Spell 是一个比较晚期才拆出来的模块。之前 AttackSpell 和 HealSpell 的代码有很多重复，我在迭代的时候把公共部分抽到 Spell 里面，这样两个子类只处理与自己相关的逻辑，扩展性也变得好很多。

3. 主逻辑模块（Adventurer / Parser / Factory）

Adventurer 最开始写得很臃肿，指令解析、物品管理、战斗逻辑全堆在一起。后来我专门加了：

• Lexer / LrParser：把字符串解析交出去

• Factory：专门生成物品和法术对象

• Magicbook：整理法术相关操作

这样 Adventurer 只负责“冒险者的行为和状态”，整个人更轻了，也符合单一职责原则。

4. 架构迭代

• 瓶子从一个类拆到四个类：测试发现 if-else 越来越多，拆分后结构更干净。

• Spell 提取父类：减少重复代码，也便于之后加新法术。

• Parser 独立出来：原来都是 Adventurer 解析，太累赘，分离后错误更好排查。

整体来说，我的架构是从“能跑就行”逐渐过渡到“分模块、分职责”的过程。

二、JUnit 使用心得

之前写 Java 基本没怎么用过单元测试，这次 OOPre 是我第一次真正把测试当作开发的一部分。

我最明显的体会有三点：

1. 测试会暴露很多隐藏逻辑
   写测试时需要把各种情况考虑进去，这促使我去思考类的边界情况。很多 bug 都是因为写测试时才意识到“原来这个地方没处理到”。

2. 写测试时更容易发现代码设计的问题
   有几次我为了写测试，不得不把某些太复杂的方法拆开，让结构更简单。测试写得越顺，说明代码颗粒度越合理。

3. JUnit 让调试不再依赖输出
   不用一直System.out.println，把注意力放在逻辑本身。

三、OOPre 学习心得

我在写这次作业之前更多是过程式思维，习惯写很长的 if-else 或者在一个文件中堆功能。学完 OOPre 之后最大的感受是：“哪些行为应该属于对象”这个问题变得非常重要。

在这次项目里有几个特别深的感悟：

• 类的设计比代码量更重要
  如果一开始类拆得好，后面功能扩展几乎不费力。

• 继承/多态能减少很多重复
  像 AttackSpell和 HealSpell，拆成两个类后逻辑清晰，也更容易查 bug。

• 面向对象让代码更像“搭积木”
  尤其是后期把 Parser、Factory 这些模块抽出来后，我感觉代码是“组合起来的”，修改局部不会影响整体。

四、对课程的两条建议

我觉得这门课整体设计得很好，但如果可以的话，我有两点小建议：

1. 关于说明结构的阅读体验
   希望文档结构能在关键小节加些小标题或总结点，这样阅读时能更快抓住重点。

2. 强测的反馈如果能更明确一点就更好了
   有时候只看到预期和实际输出不一致，但很难定位是哪一步的问题。