BUAA-oopre总结反思

代码架构

-1-主要组件结构

以价值体(commodity)为起点细分出四个主要类型,其中装备与药水各自进一步细分为三个种类.

价值体本身作为抽象的概念,以接口形式实现,主要保证价值计算相关的方法.

装备(药水)的细分以子类继承的方式,主要重写获取伤害(治疗效果)的方法.

冒险者(Adventure)是大部分行为的执行者,区别于其他几个价值体,可以拥有其他类型的价值体,主要以箱子仓库和背包两个方式拥有,物品本身存在于仓库之中,背包记录"携带的"价值体. 

 

 -2-主要行为管理部件

1.Info:输入信息管理类,负责scanner的调用,以静态方法实现各类型的输入读取

2.Fight:在第四次迭代中引入的战斗日志系统,添加此类进行专门处理,在Main中实例化一次作为战斗日志管理对象,记录内容整理借助Log类,Log类主要用于记录单条战斗记录,便于Fight对象管理.

3.Shop:在在第七次迭代中引入,主要实现商品交易功能,仅实例化一次,进行交易记录与买卖相关操作的计算.

-3-迭代中的一些反思

1.最初起步时确实低估了迭代齐次的开发规模,在最初的Adventure类中实现了过多的操作,也没有预留分散Adventure类功能的路径,导致后期开发中迭代产生的backpack等实现明显篇臃肿,多数交互都需要与Adventure进行.

2.在大约第三,四次迭代时开始关注1.中所提问题,尝试分散Adventure类的功能,实现Fight,Shop等类相关的功能尽可能压缩对Adventure的扩充,学到了很多思路,也进行了一些后期补救例如将读取操作单独作为一个类的方法分离出去,进行了尝试,取得了相当好的效果,但由于需要修改的部分散布在臃肿的Adventure的各个方法中,检查与debug过长是否艰难,也使我放弃了将输出信息部分也独立为一个类的想法,也让我切身体会到分散相关性弱的方法的重要性.

3.main类作用定位其实并没有做好,我错误估计了指令处理的工作量,尽管并不严重,但这确实造成了main类中出现了一些不合适的长段代码,不符合main类高度抽象的统筹作用.

Juint心得

junit属于是一个过去完全未接触过的部分,确实开拓了我的代码检查思路,使用junit能够对各种规模代码段的功能进行十分细致的检测:

1.对小段代码的检测主要是保证处理原件的运作是否与自己想象完全一致,对于基本的操作错误能起到准确定位.

2.对大段代码的处理,查阅了一定的资料,学到了利用System方法导入输出,导出输出,在MainTest进行了尝试,相当于在宏观上进行样例的运行,检测效果以达到评判效果,可以更便捷的连串运行一些列方法,但由于评测系统对读取输出的行为会报非法,仅在本地进行了使用,提交时仅做输入,去除了检测,这样仅能检查基本的断点报错.

oopre学习体会

1.最主要的体会就是面向对象的思考方式,过去的编程学习中主要都是针对问题,设计解决方案后按流程实现,而面向对象为我提供了新的思路,从解决问题的整体思路跳出,思考问题究竟有哪些组件,从模拟问题内各个对象行为的角度去把握住问题.我认为二者并非对立,面向对象其实是以模拟的思路将复杂的过程拆分成了更真实的小过程,在这些小过程中去细致化的打磨准确度与效率,在宏观的类对象思考中考虑可迭代性.

2.此外的一点体会便是对未知规模开发的提前规划工作,我也曾体会过上千行级别的开发实现,但那是给定的需求一次性解决,oopre第一次让我知道了在迭代情景下开发完全不同的感受,在每一次提交后都无法得知下一次开发可能需要什么,时刻都要给自己留下继续扩充的可能性,不可以为了一时的轻松而盲目的扩充一个熟悉的类,要谨慎的把可能造成臃肿的根源剔除,否则在迭代之下,修改的难度越来越大,小问题可能被不断放大.

oopre的建议

1.junit部分提到的整体检验无法在评测中进行,向助教请教了解到可能是数据输入输出流相关的包会触发作弊警告,希望能开放这些包的使用.