309
社区成员
发帖
与我相关
我的任务
分享本次作业的程序围绕冒险者(Adventurer)的行为和物品交互展开,最终架构主要包含以下核心部分:
核心类Adventurer负责管理角色的基本属性(生命值、攻击力、法力值等)、携带物品(药水、装备、法术)以及雇佣关系。物品体系采用接口与继承结合的设计,Item接口作为所有物品的基础,Equipment和Bottle作为两大物品分支,分别衍生出武器(Sword、Magicbook)、防具(Armour)以及各类功能药水(HpBottle、AtkBottle等)。通过Factory类统一创建物品实例,降低了类之间的耦合度。
迭代过程中主要做了两处关键调整:最初将物品创建逻辑直接写在Adventurer类中,导致新增物品类型时需要修改多个地方,后来引入工厂模式,将创建逻辑集中到Factory类,符合开闭原则;另外,早期的雇佣关系只处理直接上下级,在加入战斗和援助功能后,扩展为支持间接上下级关系的检查,并通过队列实现了层级遍历,确保关系判断的准确性。
在测试过程中,JUnit最大的价值在于能够快速验证功能的正确性。比如测试战斗系统时,通过编写测试用例可以固定输入条件(如特定装备的攻击力、目标防御力),重复执行验证输出是否符合预期。
印象较深的是测试药水使用逻辑时,原本手动测试容易遗漏"使用后物品从背包移除"这个细节,而通过单元测试可以明确检查使用前后的物品列表变化。虽然编写测试用例需要额外时间,但在后续修改代码时,跑一遍测试就能快速发现是否引入新问题,反而节省了调试时间。
从面向过程到面向对象的转变是最明显的收获。刚开始写代码时,习惯用函数实现功能,比如把"使用药水"写成一个独立函数,需要传递多个参数。学习面向对象后,理解了将数据和操作封装到类中的优势,比如Bottle类自己实现use方法,调用时只需bottle.use(user, target),代码更直观。
继承和多态的应用让代码扩展性更好。比如同样是装备,Sword和Magicbook虽然攻击方式不同,但都继承自Weapon,在Adventurer类中可以统一用Weapon类型管理,新增武器类型时无需修改现有逻辑。这种设计思想比单纯堆砌功能的编程方式更有生命力。