前言
经过九周的面向对象程序设计先导课的学习,先后面对了多次迭代、bug修复等流程,我对于面向对象程序设计方面的内容有了更加深刻的理解。本篇博客分为三部分:迭代作业最终架构,JUnit使用心得以及课程学习的心得与建议
迭代作业最终架构
我认为迭代作业的关键就在于整体架构的设计,良好的架构设计在面对多样的设计需求时可以轻松应对并无需大量修改,不好的架构有时则迫于需求而重构。首先,Adventurer、Bottle、Equipment、Food等基本类型作为单独的类是必要的,每一个种物品都需要满足很多的属性及行为。其次是有关输入数据的处理以及分类操作部分可以看作一类,方便对于各种操作的管理以及让main类设计的更加简洁。最后,作为Bottle、Equipment的子类RegularBottle、ReinforcedBottle、RecoverBottle、RegularEquipment、CritEquipment、EpicEquipment,因各自属性、方法不同也有必要单独成类并赋予父类的通用属性、方法。由于计算价值的需求,我们需要设计价值体接口(Commodity),从而可以对各种分类的价值体的价值属性进行管理。
从全局观念来看,我们可以用Hashmap结构分别统一管理全局的Adventurers、Bottles、Equipments、以及Foods,每个物品包括冒险者的id的唯一性确保了如此操作的可行性。统一的管理为查找、添加、删除等操作提供了极大的便利。类似的,对于每个冒险者也可以用Hashmap结构对其拥有的各类物品进行管理。而对于每个物品的背包属性,由于已有每个冒险者的物品管理,我们不需要再明确物品的拥有者,只需要通过布尔值确定其是否在背包中。对于商店,可以将其看作一个虚空的魔盒,不需要让它成为具象化的示例,只需要记录有关的数据如购买记录等即可。对于战斗日志,由于同一日期下可以发生多次战斗,所以需要单独将它作为一个类管理,否则无法区分同一天的不同战斗场景,战斗日志的属性只需要记录当前状态下战斗模式的冒险者以及战斗日志本身的字符串内容(需要用时再进行解析)即可。
JUnit使用心得
在迭代作业中对于JUnit的使用也是作业考查的重点。JUnit对于代码的正确性验证有着很大的帮助。在JUnit有关的Test文件中,我们可以通过构造样例来验证各部分代码的正确性,从而减小出现未考虑的错误的概率。JUnit对于迭代代码的覆盖率越高,代表着代码完全正确的概率越大,当JUnit测试不通过时,我们还可以根据报错信息修改代码的相关bug,这对于较大量代码的debug工作有很大帮助。在编写测试样例时需要脱离已写的代码,从题目需求本身出发构造数据,只有这样才能达到JUnit的目的。
课程学习心得与建议
在经历了完整课程之后,我感受颇深。在上课听讲的过程中,我深切感受到了吴老师对于我们的殷切期望,让我们在最后一次作业中通过写博客的方式总结自己的经历,可以看出老师对我们的良苦用心。在完成作业的过程中,有很多助教和同学比如宁然学长、胡健同学都愿意拿出自己宝贵的时间与我进行交流讨论,让我请教,我十分的感激。课程对于我的编程能力上的提升我肉眼可见,希望在之后的OO正课上能够有更大的收获!