架构设计及考虑

架构设计

类图

最终程序共有22个类，其组织方式如下。

MainClass

程序入口，调用Print进行输入解析。

Print

解析输入，随后调用各个方法实现功能。

Adventure

冒险者类，因为几乎所有操作都以冒险者为主体，所以大多数功能需要这个类参与实现。

Fight

专门控制战斗的类。

Employment

专门控制雇佣关系的类。

Fragment

专门控制碎片的类。

CE接口

连接冒险者游戏中的所有实体对象（均有CE）：

• Adventure
• Bottle父类
  • AtkBottle
  • DefBottle
  • HpBottle
• Equipment

Guard接口

连接所有工厂中的守卫：

• Shd
• Flm
• Stn
• Wnd
• Frz

Treasure接口

连接所有守卫对应的宝物：

• ShdTreasure
• FlmTreasure
• StnTreasure
• WndTreasure
• FrzTreasure

架构考虑

• 在学习了继承和接口之后，我重构了代码以增强类之间的逻辑关系，将各类药水瓶用父类形式实现，并使用接口关联起了冒险者，武器和药水瓶。在此后的工厂中也使用了接口。
• 对于复杂的功能，构造单独类来实现，例如Fight类，由于战斗过程复杂，单独提取出一个类，提高了代码的模块化程度。
• MainClass类只用来进入程序，随后就进入Print类负责解析输入输出。

Junit心得体会

Junit单元测试是我们在OOpre课程中首次接触到的一种测试方法。他为我们提供了单独测试某个具体模块的机会，当然这机会的出现也跟java自身面向对象的特点相适应。

在进行Junit单元测试时，我们应该进行自下而上的设计，先分别测试底层的功能能否正常实现，然后在确信底层无BUG的情况下去构造测试去测试更高层的方法，这样有利于我们快速把握问题所在。

覆盖率是判断Junit测试有效程度的重要指标，也是OOpre课程的要求，我们今后在编写java程序时，就算没有强制要求，也应该养成保证Junit覆盖率的习惯。因为没有被测到的边边角角是最容易滋生BUG的。

OOpre心得体会

刚开始学习OOpre的时候真的感觉非常新奇。因为面向对象编程的体验和此前完全不同。别的不说，创建一个新类后光靠代码补全就啪啪啪敲出一大堆内容的感觉真的很爽。

不过到后期的迭代就老实了。此前我从来没有上过像OOpre这样的带有强测的课程。所以第一次需要修bug的时候真是死去活来，后面跟室友讨论才发现原来是重复携带上出了问题。不过最后一次倒是熟练了，找室友对拍了一下发现我的问题在于一次秘境探索比正常情况多闯了一关，找到对应的指令打个断点一看发现我居然携带了两个同id的药水瓶！具体问题出在哪就不说了，太丢脸。这个bug本该在第四次作业就暴露出来的。

建议

• 弱测可以稍微强一点点（）