OOpre 课程总结

相比其他一般专业课，oopre的课业繁重，但是也同样令我学到了很多东西。

作业架构

初次构建

一开始我的架构其实只有main类、Adventurer类及附属的Bottle、Food、Equipment,十分扁平，处理输入和指令操作都通过main方法实现，主要操作堆叠于Adventurer类

后期改善

随着迭代进行，我发现这样并不能很好地处理相关操作，并且会出现main方法过于臃肿的问题，另外随着迭代也形成了新的架构：

新增类

• 将指令操作从main方法中剥离，形成了Operation类
• 新增Bag类，用于处理背包相关操作
• 新增Fightlog类，专门处理战斗相关问题，分为fight、fightMode、fightFeedBack、getFightLogs方法,分别用于处理战斗输入、战斗模式、战斗反馈相关输出以及战斗日志存储、获取战斗日志
• 单例化实现商店Shop，并将其与Factory连接用于获取生产新物品
• 工厂Factory用于生产各种物品

接口&继承

Extend

• ReforcedBottle、RegularBottle、RecoverBottle继承Bottle类
• RegularEquipment、EpicEquipment、CritEquipment继承Equipment类

其实regular的功能与父类完全一致，只是为了判断类型方便才进行扩展

Implement

接口Commodity用于处理各种价值体并且获取价值。

• Commodity
  • Adventure
  • Bottle
    • RegularBottle
    • RecoverBottle
    • ReinforcedBottle
  • Equipment
    • RegularEquipment
    • CritEquipment
    • EpicEquipment
  • Food

接口Employer和Employee均用于Adventurer,用于实现雇佣小队

最终架构

其实还有很多结构上可以改善的地方，例如建立一个公共的类管理冒险者和物品并提供对应的查询方法，可以避免将冒险者传入不同类的操作等等

---

Junit使用心得

其实作为一项测试工具，我在这方面的应用并不是很熟练，尤其是中间重构过代码，导致每次写Junit都很痛苦，后面两次迭代架构趋于成熟，测试起来就会舒服很多。

• 多用断言而不是输出来判断正误
• 尽量考虑测试更多的分支来达到判断的目的
• 尝试构建错误数据观察报错
• 尝试构建极端数据来观察结构
• 有调用其他类的情况在被调用的类中单独对被调用类进行测试以判断错误出现地点

越到后来越感觉到这是一个测试工具而不是用于应付了事

OOpre心得体会

• 在处理不同属性时要根据属性自身功能和要求去构建方法，不能强行耦合数据，比如Bottle的capacity属性使用后不能置为0，而是应该建立Boolean whetherEmpty用于标志是否为空
• 封装是一件很重要的事，建立对应方法同样如此
• 将类的功能进行拆分，不能过渡延展某一个类实现的功能，应该形成多个独立的类或者进行父类与子类的划分
• 不要在A类的某一方法中调用太多B类中的方法，应该对这些方法进行封装
• 尽量在类中实现单层调用，不要进行多个中间调用
• 命名具有可读性，望文生义

课程建议

其实可以对弱测数据稍微加强一点点，至少做到新增加的功能全部覆盖