2025-OOP-总结

[李清伶-ZC061003]

作业架构

一、主流程：MainClass

MainClass 基本就是输入解析 + 指令分发。

二、业务对象模型：Adventurer + Manager

1. Adventurer 类

它包含：
    •    基础属性（HP/ATK/DEF/Mana/Money）
    •    所有物品 （bottles、equipments、spells）
    •    背包和已装备物品
    •    雇佣关系
    •    业务行为（use、takeDamage、清理雇佣、判断上下级、判断盟友…）

2. AdventurerManager 承担了协调者的角色

它处理：
    •    创建物品
    •    为冒险者添加物品
    •    执行战斗
    •    执行 use 行为的校验规则
    •    检查援助、计算下级治疗等复杂流程
    •    管理雇佣关系添加/解除

把所有复杂逻辑都转移到 Manager，而 Adventurer 只保留基础行为，这一步其实是我向ai提问、与同学交流后才进行的操作，算是一次明显的架构调整，让我逐渐对面向对象的思想有了一些体会，即把变化的业务处理从稳定的地方抽取出来。

三、设计演变（迭代中隐含的架构调整）

 1. 将物品类型逻辑抽象成 Factory

最开始是直接 new，不同瓶子/装备靠 if 判断；后面我把物品创建收敛到 Factory，因为随着迭代开发，需求不断增多，new 变得乱，就需要逻辑集中化，也是将架构逐渐模块化的过程。

 2. use/fight 逻辑从 Adventurer 移到 Manager

最开始是 Adventurer.use(item)，后来操作越来越复杂：上下级限制、盟友限制、事件触发，所以我把逻辑移到 Manager，并让 Adventurer只执行自身行为。因为：

Adventurer 是“对象”，不是“业务流程驱动器”。
复杂规则属于“服务层”，不是实体层。

四、待改进部分

1. MainClass 过度承担逻辑

（从checkstyle反应我main方法过长就能看出来。）

应该再做些拆分等等。

2. Manager 的职责像“大杂烩”

买东西、战斗、援助、雇佣关系，全都塞在一起。
或许可以再拆成：
    •    CombatService
    •    EmploymentService
    •    InventoryService
    •    EventSystem

3. Adventurer 类过重

4. 没能完成全部作业题目要求

使用JUnit的心得体会

一些注意事项：

1. 单测必须独立、可重复
       •    每个测试用例（@Test）必须互不依赖。
       •    不能依赖执行顺序，不能依赖前一个测试留下的变量或状态。
2. “一个测试只测一件事”。
3. 不要在测试里写复杂逻辑
4. 减少 I/O，简化构造对象流程

学习OOPre的心得体会

学习oop这门课，让我第一次真正体会到了“解耦”和“模块化”这些概念的意义和价值。以前写程序时，总是按照“步骤—流程”那一套来组织代码，越写越乱，功能一多就很难维护。通过这门课，我逐渐学会站在“对象”的角度去思考问题，把程序拆成一个个彼此独立、职责明确的模块。

这种从过程转向对象的思维方式，的确让开发变得更高效。类与对象之间清晰的边界、接口之间的分工，让我在写代码时更容易扩展功能，也更容易定位问题。尤其是在处理稍微复杂一些的需求时，能够明显感受到模块化设计带来的便利——代码结构更清晰，维护成本也降低了。

总的来说，这门课不仅让我掌握了基本的面向对象技巧，更重要的是改变了我设计程序的方式，让我开始从更高的层面去思考软件的结构与可维护性。

 

对OOPre课程的简单建议

个人觉得前期（尤其是刚上了一两次课的时候）学习曲线太陡峭了，跟不上，希望可以加一些规模小点的题目作为练习和热身。

老师和助教辛苦啦！