2025 oop第八次作业

侯博渊-24373120 2025-11-11 21:20:32

一、作业的架构设计

1.架构概述

本学期oop实现了一个冒险管理器系统，支持冒险者创建、物品管理、战斗机制、雇佣关系维护等核心功能。架构设计严格遵循面向对象（OOP）原则，采用 “模块划分 + 职责单一” 的设计思路，整体分为 5 大核心模块，模块间通过接口协作。

2.大致架构图（只有社区版的鼠鼠是这样的）

3.核心模块职责

（1）控制层：AdventureManager 作为 “中枢”~~（类似于co的CU）~~，负责接收操作指令、校验参数、调用各模块完成业务，如战斗、物品使用，并处理结果输出。
（2）实体层：Adventurer 封装冒险者的属性，如血量、攻击力等，和行为，如学习法术、使用物品；HireRelationManager 维护雇佣层级关系，支持上下级查询、盟友判断。
（3）物品层：通过接口和抽象类定义物品行为规范，具体子类实现差异化功能，如 HpBottle 回血、AttackSpell 攻击。
（4）工具层：Factory 统一管理对象创建，降低耦合；Lexer+Parser 处理复杂雇佣关系输入，即嵌套雇佣指令。
（5）入口层：Main 负责解析控制台输入，将指令传递给 AdventureManager 执行。

二、迭代中的架构调整及考虑

1.最初设计痛点

最初未设计 Factory 类，物品创建逻辑分散在 AdventureManager 中，导致代码冗余且难以扩展，新增物品需修改控制器。
雇佣关系仅支持直接上下级，未考虑 “层级传递”，如雇主的雇主也是上级，且关系维护与业务逻辑耦合。
援助消息（helpMessages）直接在战斗方法中打印，违反 “单一职责”，且无法复用。
2.关键调整

（1）引入工厂模式
将 Bottle、Spell、Equipment 的创建逻辑抽离到 Factory 类，通过静态方法统一创建对象。
考虑：符合 “开闭原则”，新增物品时无需修改核心控制器，仅需扩展 Factory 和实现对应类。
（2）拆分雇佣关系模块
在 AdventureManager 中新增 helpMessages 列表，战斗或物品使用后先存储援助消息，再通过统一方法 printHelpMessages 打印。
考虑：避免业务逻辑中混入打印逻辑。

三、使用 JUnit 的心得体会

JUnit 让我深刻体会到自动化测试有效性。在实现核心功能时，先编写测试用例，再实现业务逻辑，能提前发现边界问题，如冒险者死亡后无法操作、雇佣关系循环引用。
实践中的关键技巧
测试用例设计：针对单一方法设计多场景用例，覆盖正常流程、异常流程，如传入不存在的冒险者 ID）、边界值，如血量刚好为 0、雇佣关系层级达到 3 级）。
解耦测试依赖：对于依赖外部输入的方法，通过模拟输入数据编写测试，确保测试独立性。
断言的精准性：使用 assertEquals、assertTrue 等断言时，明确校验核心结果，如战斗后目标血量、雇佣关系是否成立，避免模糊断言。

四、学习oop 的心得体会

1.从面向过程到面向对象的思维转变

（1）面向过程编程的核心是 “步骤”，比如实现 “战斗” 功能时，会按 “计算攻击力→计算伤害→扣除血量” 的步骤写函数；而面向对象的核心是 “对象”，将战斗拆分为 Adventurer（计算攻击力）、AdventureManager（协调流程），每个对象职责单一，代码更易维护。
（2）封装、继承、多态的实际价值：封装让属性安全，如冒险者血量通过 setHitpoint 控制，避免直接赋值为负数；
（3）继承减少重复代码，如 Bottle 子类无需重复实现 getId、getEffect 方法；
（4）多态让代码灵活，如 HealSpell 和 AttackSpell 都实现 use 方法，AdventureManager 无需区分具体类型即可调用