OOpre_2025课程总结

血的教训

csdn写帖子的时候务必要保存！刚刚因为没有保存痛失一篇即将完工的文章。

一.代码架构

 从c语言到java的转变,不仅是从面向过程编程到面向对象编程的转变,更是main函数逐步缩短的转变.

还记得上学期数据结构课上,我的main函数代码简直是"懒婆娘的裹脚布--又臭又长",这也导致我在debug过程中极为煎熬,花了很长时间才能找到是哪个main函数中的部分出现了问题.经过多次作业的迭代,我的代码主要可以分为以下几个部分:

(一) 代码作用

1. CommandHandler.java 命令处理类，负责解析并处理各类输入命令（如 "aa" 创建冒险者、"ab" 添加药水、"fight" 战斗等）。针对不同命令实现了对应的处理方法，调用其他类（如AdventurerManager、Factory）完成具体逻辑，并输出处理结果。

2. Factory.java 工厂类，提供统一的物品创建接口。负责创建药水（Bottle）、装备（Equipment）、魔法（Magic）等对象，根据输入的类型参数返回对应的具体实例（如根据 "HpBottle" 创建HpBottle，根据 "armour" 创建Armour）。

3. AdventurerManager.java 冒险者管理类，维护一个存储冒险者（Adventurer）的集合，提供添加冒险者（addAdventurer）、获取冒险者（getAdventurer）等方法，统一管理所有冒险者实例。

4. Magic.java 魔法类，实现Usable接口，定义魔法的属性（ID、类型、魔力消耗、威力）和使用逻辑（use方法）。支持治疗（"HealSpell"）和攻击（"AttackSpell"）两种效果，使用时消耗使用者魔力并作用于目标。

5. EmploymentRelation.java 雇佣关系管理类，维护冒险者之间的直接 / 间接雇佣关系（上级、下级）。提供添加 / 移除雇佣关系、查询上级 / 下级 / 盟友等方法，用于判断战斗或使用物品时的关系约束（如不能攻击上级、只能对盟友使用物品）。

6. Lexer.java 词法分析器类，用于解析输入字符串，提取令牌（如 ID、括号、逗号）。通过next和peek方法遍历并获取输入中的有效 token，可能用于命令的语法解析。

7. Equipment.java 装备基类，定义所有装备的共同属性（ID、类型、战斗力ce），提供属性访问方法。是Armour、Weapon等具体装备类的父类。

8. Usable.java 可使用物品接口，定义use方法，规范所有可使用物品（如Bottle、Magic）的使用行为，确保它们都能被统一调用。

9. Bottle.java 药水基类，继承自Usable接口，定义药水的共同属性（ID、类型、效果值）和使用逻辑（use方法）。子类（如HpBottle、AtkBottle）通过实现applyEffect方法定义具体效果。

10. Weapon.java 武器抽象基类，继承自Equipment，作为所有武器（如Sword、MagicBook）的父类，统一武器的基础结构。

11. Adventurer.java 冒险者类，核心实体类，包含冒险者的属性（生命值、攻击、防御、魔力、金币等）和行为（携带物品、战斗、使用物品、学习魔法等）。管理自身的药水、装备、魔法，并实现物理 / 魔法攻击、购买物品等逻辑。

12. Main.java 主程序入口类，负责读取输入命令、解析命令参数，并根据命令类型调用CommandHandler的对应方法处理。是程序的总控逻辑。

(二) 代码问题

虽然经过了这么多次的迭代,我代码中的问题可谓是犹如长江之水源源不断,旧的去了新的又来,第七次作业后,我仔细总结了,发现我的代码主要存在以下几个问题:

1.我的代码中的雇佣关系计算效率低下,EmploymentRelation的updateTransitiveRelations方法在每次添加 / 移除雇佣关系时，会全量重新计算所有冒险者的上下级关系（通过calculateAllSuperiors和calculateAllSubordinates遍历所有节点）。因此我的方法在实际工程中是绝对不可实现的(如果真的要设计成为一款游戏的话),但是目前没有想到一个非常好的方法来解决我的问题.

2.我的代码之间的关系过于紧密,难以编写测试文件,需要同时考虑几个不同类之间的问题,导致写test代码时候效率非常低.

(三) 架构调整

在第一次和第二次作业之后,我将bottle分为了每个小类,同时为魔法专门引入了magic类,还为了减少main函数的逻辑,引入了commandhandler类,否则我的代码风格分每次将会扣20,同时我还将equipment细分,分为物理和魔法工具,如weapon,magicbook,编写代码时秉承的原则就是一个java文件中的代码越少越好,可以多开几个类,允许横向扩展,缩短纵向长度.

二.JUnit使用心得

在编写了很详尽的test代码后(不然达不到要求覆盖率),我发现原来这个junit的使用也提示着我们要减少main逻辑的代码量,然后就是junit确实对debug很有用,一开始我有点对着答案写test代码,但是仔细一想,这不是课程组让我们使用junit的用意,于是后面坚持按题目逻辑编写,这也为我debug提供了便利.

三.OOPre学习体会

OOPre 的学习让我跳出了 “按步骤写代码” 的固有思维，学会了用 “抽象实体、定义交互” 的视角看待问题。这次作业中的每一个类（如Adventurer、EmploymentRelation、CommandHandler）都有明确的职责，它们之间的协作构成了整个程序的逻辑，这种模块化的设计让代码更易维护、更易扩展。未来，我会继续深化对 OOP 设计原则的理解，在实践中完善封装、解耦和异常处理，让代码不仅能实现功能，更具备良好的设计美感。

四.对课程的建议

1.提供中测测试代码反馈,可以将测试点输入输出都给出.

2.减少迭代作业的次数,可以不减少工作量.