一.最终架构及说明

框架如图所示

控制部分

Main
CommandProcessor
Factory
Lexer

操作对象

• Adventurer
• Item
  • Bottle
    • AtkBottle
    • DefBottle
    • ManaBottle
    • HpBottle
  • Equipment
    • Armour
    • Weapon
      • Sword
      • MagicBook
• Spell
• UsableItem（接口）
  • Bottle
  • Spell

二.历次迭代中的调整与思考

第一次迭代：容器

第一次迭代把整个项目最基础的一些物品进行了实现，并且通过容器来管理（实际上当时还只会ArrayList，后续进行了修改）。在一开始我意识到对指令的解析和操作部分一定会不断扩展，所以写了一个CommandProcessor类来处理指令，没有直接在main方法中处理，避免了后续的调整。

第二次迭代：继承和接口

利用继承机制划分了不同的药水瓶。利用接口UsableItem来实现了Bottle和Spell的use方法。最后是关于背包，我再设计了一个父类Item让Equipment和Bottle继承，通过Item的容器来管理携带的物品（为下一次复杂的选择埋下伏笔了）。

第三次迭代：新容器和工厂模式

1.内容上装备进行了细化，故新增了一些子类。对装备的属性进行了定义。对背包携带物品数量进行了限制，装备和药水瓶各有上限。定义了战斗规则和金钱系统。
2.这里就出现了一个问题，战斗需要已携带的装备的属性值，我想到两种思路：一是新定义一个冒险者的用于战斗的属性，每次更新携带的装备时更新，携带的装备仍然在背包里，二是把携带的装备作为冒险者的属性（因为数量只有1，非常特殊），背包实际上只装了携带的药水。我采用了后者，原因就在于数量的特殊和使用的规则不同于药水瓶这样的消耗品，让我更倾向于把其作为属性（不知道是否合适）。
3.金钱系统需要实现的两部分，购买在CommandProcessor中用一个方法实现，战斗导致的金钱变化通过又一个新方法，战斗后调用该方法更新冒险者的金钱属性。
4.采用了工厂模式来封装多种实例化过程。

第四次迭代：观察者模式

雇佣关系实现，采用类似观察者模式，用hashset来存储直接下级，写了一个递归方法得到所有下级，同第三次一样，我将直接上级也作为属性。

第五次迭代：递归下降法

对一个规定的雇佣关系输入指令解析，采用递归下降法，实现了对指令的解析和执行。

三.Junit使用体会

JUnit的使用让我体会到了单元测试的重要性。以前都是通过控制台输出人工比对debug，在逻辑复杂的情况下极为麻烦。通过JUnit的自动化测试，为每个类和方法编写测试用例，同时断言功能使得验证预期结果变得简单直观（终于不用肉眼观察了），大大提升了测试效率，并且对于边缘数据的测试也更直观，不会再因为人为因素遗漏。

四.OOpre课程心得

OOpre课最大的收获是让我对于“对象”有了一定的理解。过去的面向过程编程，注重的是对流程和数据一步一步的操作，而面向对象我的理解是将数据和操作封装在对象中，通过对象之间的交互来实现功能。“对象”作为一个实体或概念的抽象，封装好了我们需要的数据以及用于实现功能的方法，这样我们在进行更高层的设计时，不需要再关注对象内部的复杂细节，只要描述对象间的行为即可，对于复杂工程来说，这种简化效果极其有益。
除此之外，checkstyle也让我获益颇多，尤其是规范命名，这很大程度上避免了命名冲突和理解错误，提高了代码的可读性，在维护时也更加一目了然，这个习惯对于其他语言也是可迁移的。

五.课程建议

指导书可以更加详细一些，比如实例代码可以更加丰富，然后一些内容讲述顺序可以略调整，比如容器的部分可以都放在一次靠前的讲解，更系统也更好比对各类优劣，同时也便于后续的扩展和维护。