271
社区成员
发帖
与我相关
我的任务
分享目录
本学期OOpre作业为达到Junit的方法覆盖率要求在Main类下面包了一层Launch类,由Launch类行使总线功能。Launch类配合Lexer类实现了对输入的解析并通过Launch类中的AdventurerArray实现了对所有Adventurers的管理,又通过Launch类中的各种方法实现了对Adventurer类中方法的调用以实现方法对应的功能。由于编程思路基本就是直接刻画游戏中不同Adventurer的行为,因此基本所有的命令的执行都会先调用Adventurer类中的方法,之后再根据命令牵涉到的不同物品调用更次要的方法。
根据题目的要求对物品分为以下几类:Equipment (Armour, Weapon (MagicBook, Sword) ), Spell, Bottle(AtkBottle, DefBottle, HpBottle, ManaBottle)。其中Spell类虽然分为AttackSpell和HealSpell, 但为方便管理只为Spell类增添了标明该Spell功能是Attack还是Heal的属性,并未构造子类,但判断Spell具体类型循环查找Spell等操作会损失性能。以上物品的构造购买集成在Factory类中。
为实现背包以及可用物品等的动态管理设置了Usable和Bag接口,其中Bag接口原本管理Bottle和Equipment两类,在对Equipment实现每个Adventurer最多只能携带Armour和Weapon各一个的数量限制功能后仅管理Bottle类,将Adventurer携带的Armour和Weapon设置为其属性。
最终在完成雇佣关系时通过Boss和Employee接口以观察者模式实现。
根据前文提到的编程思路,在迭代时一定会根据新增指令或新增功能需求先修改或增删Launch类和Adventurer类的属性以及方法来完善逻辑,再根据情况判断是否需要增添接口、构造子类或构造新的类。
JUnit确实可以辅助检查出bug,尤其是为达到分支覆盖率和行覆盖率要求需要尽可能考虑到所有的情况,可以督促我更深入全面地思考问题、理解功能逻辑。由于语言不够熟练、思路不够清晰,目前还不能做到测试驱动开发,未来向这个方向努力~
在OOPre课上从面向过程编程过渡到面向对象编程,对程序开发思路有很大启发。从前思考问题是单线程的,习惯按照时间顺序梳理每一步的逻辑,并且使用面向过程的思路很难实现对多主体管理。面向对象的编程方式能更直观地实现对不同对象之间的物理逻辑的刻画,在编程时逻辑更清晰严谨,但也不能丢弃指令执行先后的时间顺序。在进行面向对象编程时,我习惯先理清各个类之间的主次关系,再自顶向下编写代码。
不论面向对象还是面向过程,我都需要进一步提高debug能力。我一般在以下几个方面容易出现bug:
(1)读题时不够认真,出现没注意到底是>=还是>之类的问题
(2)实现过程中漏掉了一些步骤例如忘记对某些属性进行同步修改
(3)解决问题时出现逻辑错误例如错误判断先统计元素数量还是先remove
希望可以使每次作业量更均匀