OOPre第八次作业（课程总结）

[江秀莹-74066204]

1.作业最终整体架构设计

1.1架构设计

如图
整体上，我把代码程序分成几个部分：

1. 指令处理部分：
   Main 负责读入指令并分发给 MainLogic，MainLogic 根据 type 调用对应方法，以避免在 main 里堆太多业务代码导致 Junit 测试挂掉。（本人一直把业务代码堆到 main 然后很后面才发现 Junit 其实不会测到 main里面的方法·）

2. 核心业务部分（Adventurer + 物品）：
   Adventurer 是核心类，负责管理一名冒险者的：

• 基本属性：hitPoint / atk / def / mana / money
• 物品：药水瓶、装备、法术
• 状态：是否死亡、最终攻击力 / 防御力
• 操作：携带物品、使用物品、战斗、结算金币等

物品这边我用继承做了一个层次：

• 药水：Bottle → HpBottle / AtkBottle / DefBottle / ManaBottle
• 装备：Equipment → Sword / Magicbook / Armour
• 法术：Spell → HealSpell / AttackSpell
  这样在处理 use、fight 的时候，就可以先按父类处理，再根据具体子类决定是加血、加攻、防御还是扣血，这样代码会清楚一点。

3. 关系和解析部分：
   雇佣关系的话， 我是直接放在 Adventurer 里，然后用 employerId 记录上级、employeeIds 记录下级，再用小方法判断“是不是上级 / 是不是盟友”，所有 use、fight 之前都会先用这套关系过一遍。援助也是在同一个关系里往下找下级，看谁能放治疗法术帮忙加血。然后，lr 指令则用 Lexer + LRParser 把 King(Knight(Archer),Rogue) 这种字符串解析成一堆雇佣关系，也相当于一次性做很多次 ar。

1.2 在迭代中的架构调整及考虑

第三次迭代：
我新增了MainLogic代码，让Main 只负责读输入就好；我在 MainLogic 里集中写创建物品的方法（像简易工厂），而战斗和背包的细节都交给 Adventurer。

第四次迭代：
在 Adventurer 里加 employerId / employeeIds，然后用 isSuperior / isAlly判断“是不是上级 / 是不是盟友”，这样所有 use、fight 指令统一先用这两个方法检查关系，再决定能不能动手，这样雇佣规则就只用写一遍，别的地方直接复用就好了。

第五次迭代：
我另外写了 Lexer 和 LRParser 两个类，专门把 A(B,C(D)) 这种 lr 字符串拆开，解析他们的雇佣关系，再丢回原来的建关系逻辑里，这样也考虑到“解析字符串”和真正业务是分开的，后面debug就会更好改。

2. 使用JUnit的心得体会
一开始我完全不会写测试，我甚至不懂这个是什么来的。我只会把assertEquals 改一改，再不行求助ai。后来慢慢习惯先写几条简单的用例再改代码。在这几次作业里，我主要给 Adventurer 的加血 / 加攻、防御、金币结算，还有各种Method写了单元测试，顺便把边界情况（血量到 0、钱变成 0、属性上限）都跑一遍。总体感觉是，虽然一开始写测试有点麻烦，但后面迭代越来越多，能直接复用以前的测试来帮我检查，比人工对拍检查方便很多，不然就我不懂要检查多久那个代码错在哪。

3. OOpre学习心得
上这门课之前，我只会写 C和Python(也忘得差不多了），我习惯把逻辑一股脑写完，最多拆几个函数，函数之间靠一堆参数和全局变量在那边互相传。刚开始写 Java 的时候，完全不习惯先想对象这种写法。什么都要先想“类”和“对象”，感觉写个小功能也要绕一大圈，有时候自己都会绕晕不懂在写什么。从过程到对象，对我来说最大的变化是思维方式吧。比如我不再是想写完这道题过了测试点就结束，而是会先想以后还要在这个基础上迭代几次，我现在这样写后面很难改怎么办？就开始意识到封装、扩展性那些的重要性，主要是不想被自己之前写的代码坑。

4. 对OOPre的建议

1. 我个人建议描述题目的时候尽量写得更简单易懂一点吧，感觉现在的语言能力还跟不上。谁懂留学生最大难关不是写代码而是看得懂题目啊！
2. Git配置工具的这个教学确实需要改进一下，我当时安装下载配置这些做到怀疑人生，还以为没写代码我就栽在这里了。