面向对象先导课程总结

项宇浩-24371047 2025-11-11 12:50:46

总结方面

作业最终的架构设计, 在迭代中的架构调整及考虑
使用 JUnit 的心得体会
学习 OOPre 的心得体会（包括但不限于从面向过程编程过渡到面向对象编程的体会）

架构设计

架构需求

这次迭代作业需要实现以下几点：

使用 bottle 修改属性
使用 spell 修改属性
使用 equipment 处理攻击
实现雇佣，处理阵营问题

总结需求

分析需求，我总结了一下几点：

为了避免 Main 类的代码量过大，新增了一个 Manage 类，用于分析输入。
由于有多个 Adventurer，所以用 Adventurers 类来管理这些 Adventurer。
Factory 管理生产所有东西。
Equipment 和 Bottle 都需要携带、删除，所以增加它们的父类 Item。
Bottle 和 Spell 都需要 use，所以增加它们的接口 UsableItem，但同时 use 也要考虑阵营问题，所以我新增了 NotAllowed 接口。
Parser 和 Lexer 用递归下降的方法，分析雇佣输入。

架构调整

在第五次迭代的时候，我对之前的代码架构进行了优化。

之前我统一把 Bottle， Spell， Equipment 归入 Item，然后用一个 Action 接口实现 use，这会产生一些问题，

Equipment 不涉及 use，所以如果让它也接入 Action 接口，不能很好地处理接口实现问题。
Spell 是永久性的，和 Bottle， Equipment 归在一起不能很好地区分。

之前的架构图如下：

后来我总结出 Equipment 和 Bottle 具有相同实物的相同点，即需要携带、删除等，Bottle 和 Spell 有相同点，比如都需要 use，所以将 Item 和 UsableItem 分离开，这样，Bottle 兼有了 Item 和 UsableItem 的特性。

后来的架构图如下：

但是对代码的重构并非易事，即使重构后的代码架构会明显更合理。第五次迭代因为采用了重构的策略，出现了很多细节问题，所以导致强测没能顺利通过。但是这样的重构对后来的迭代做了铺垫，后面几次迭代感觉到结构更清晰，修改不容易出错。

架构思考

这几次迭代中，我独立形成架构，我的原则是，能用更简便的方法实现功能，就不用新增类和接口，不用更复杂的数据结构。

比如说，处理 fight 指令时，我没有像 use 单独设置接口，而是直接在 Adventurer 中定义方法实现。考虑如下：

fight 的使用武器种类较少，没有像 use 一样这么高的重合度，武器已经作为了 Adventurer 里面的单一属性。
fight 中更多的是考虑 adventurer 以及 adventurer 之间的属性联系，定义其为 Adventurer 里的方法更直接。

使用 JUnit 的心得体会

JUnit 可以单独测试类，能产生局部测试的效果，比如说当我编写 AttackSpell 的时候，我忘记在 changeHitPoints() 中写负号，导致体力值不能正常减少，这样的漏洞在当时的 JUnit 测试中就找到了。同时，也要善用 @Before, @Test 来处理建立对象和测试对象的问题。要充分考虑边界值，如null、空集合等，用 JUnit 的 assertThrows 验证异常。