2025OOPre课程总结

[娜仁丽丽-70066008]

最终架构与迭代过程概述

最终作业folder构架

├───src
│   ├───adventurer
│   ├───items
│   │   ├───bottles
│   │   └───equips
│   ├───parser
│   ├───relation
│   └───spells
└───test
    └───src

在前几次迭代中，很多操作逻辑都集中在一个文件，比如物品操作、战斗、雇佣关系、使用物品等部写在 Adventurer.java里。但随着需求变多，这种结构开始出现维护困难、重复代码过多的问题。最终在 HW7 收尾时，我的架构已经演变成更合理的多模块设计：

将逻辑分散到多个类协作

最初为了图方便，把所有行为（战斗、携带、使用物品、学习技能等）都写在 Adventurer 里。
但随着功能变复杂，我将职责拆分到多个类中：

• Manager：专门负责指令调度（输入处理、分派操作）

• Adventurer：只负责与自身相关的战斗、背包、物品、法术和雇佣关系

• Backpack：管理“携带状态”的物品

• relation 包：处理 lr 关系解析

• Factory：统一创建物品、装备、法术对象

从 ArrayList 存储所有物品 → 使用继承体系管理物品与法术

一开始，物品与法术只是存在一个 ArrayList<Item> 里，根据字符串判断类型，再手动处理各种逻辑。
后来随着子类变多，我引入了更标准的 OO 设计：

• Item / Bottle / Equipment

• Spell / HealSpell / AttackSpell

• Usable 接口

这让代码使用类的多态行为自动处理逻辑。

从繁琐的判断 → 用 Usable 接口统一 useUsable

早期 useUsable() 方法：

最后改成每个子类自己实现如何生效的：

从 “拥有 == 携带” → Backpack 管理携带状态

最开始的逻辑是ownedItems 里面有东西，就算“携带”，这导致：

• 删除物品和取消携带混在一起

• 战斗计算武器战斗值容易出错

新增 Backpack 类后，结构变得更加清晰：

• ownedItems：冒险者拥有的所有物品

• Backpack：当前“携带”的物品（武器、防具、可用物品）

Manager 成为真正的“调度器”

在最终版本中，Manager.handleCommand() 变成一个干净的分派器：

• 统一判断指令类型

• 调用对应的处理函数

• 不在内部写业务逻辑

• 不依赖具体 Item / Spell 的细节

这让输入逻辑与业务逻辑彻底分离，代码读起来也更安全、清晰。

使用 JUnit 的心得体会

使用 JUnit 让我体会到了模块化测试的好处：

• 每次完成一个类的功能，就可以立即编写对应测试类。

• 代码重构后，不需要反复人工验证, 只需要重新跑一遍测试，就能知道哪里出错。

不过，写单元测试会变得很困难，反而暴露了架构的问题。🥲

学习 OOPre 的心得

面向对象不仅仅是语法结构，它教会我们如何把一个系统拆解成多个小模块，各自独立又彼此协作。在这门课之前，我们更多是按照 C语言的习惯思考问题，代码集中在一个主函数中；而现在要开始把每个功能封装在类中，并考虑每个类的职责边界。我觉得对于未来 OO 正课甚至实际项目开发特别有帮助。