P4 OOPre课程总结与反思
Content:
1.迭代过程
2.最终结构
3.junit的心得体会
4.oopre心得体会
5.课程建议
一、迭代过程
1.第一次迭代
冒险者拥有装备与药水,通过方法反馈他们的私有属性。
考虑到他们的id属于特有属性,一一映射,因此我采用了hashmap作为作业的主要容器
2.第二次迭代
添加了食物和背包功能,我将背包开一个类,其拥有的属性便是冒险者携带的东西,然后冒险者的私有属性加上背包,且只有一个,进行管理。
tips:
- 此次过程中,删除背包或者拥有的物品,两边都要对容器进行删除。同时不能直接一边寻找一边删除,需要运用迭代器或者记录好,遍历后再删除。
- 同时若两个容器存的是同一个对象,也就是浅克隆,只需修改一个容器里的东西便可!
3.第三次迭代
加入战斗日志功能,笔者认为战斗日志并不属于任何一个冒险者,而是一个独立的系统,因此大体上它并不完全隶属于冒险者,只有和冒险者有关的部分才写入冒险者的日志,在整体世界观下还有一个存储所有日志的容器(放在了整个程序中)。
本部分学习了正则表达式的使用,由于题目对于每种情况区分很清楚,正则也便于写出。
本次迭代的难点主要在于是对于每种日志相关体力等内容处理,一般是细节上的,思路比较好像,具体实现容易出错。
4.第四次迭代
加入了父类与子类,以及接口。同时冒险者可以被雇佣,因此成为冒险者的一个私有属性。还加入了价值属性。
因为本次子类和父类的方法基本相同,我是只在子类中增加了other与体力计算方式(注意精度问题),由于接口我只能想到一个对其价值的获取这一共同的抽象方法,所以未加入我的结构,这也是我的整体代码缺少后续作业的一部分内容。
5.第五次迭代
加入了shop系统和援助系统,shop系统是单独于其他类的系统,无需隶属于任何一个,其对出售进行记录。援助系统利用容器记录进入战斗前的体力,退出战斗后进行援助,整体较为简单,注意细节即可。
二、最终结构
经过上述迭代形成了最终的结构。
- 并未使用相关的模式,或许是整个项目并未特别复杂,通过增加类便可以完成。但笔者对于模式的理解还是较浅,对于他们何时使用,仍有所困惑,会在后续继续思考
- 从第一次迭代,笔者的思路便是找到每一个对象的从属关系,将相应的方法写入其所属的类,自认为结构较为清晰,所以在历次迭代,并未大幅修改代码结构,整体是在原来的基础上增加,但由于不愿跳出舒适圈,所以对于后续的相关模式与接口并未积极使用。
- 笔者的选择结构使用的是每次作业作为一次switch,打包成一个类,在其中进行操作,作为方法传入main中。不过在第五次作业时,看到了给的示例代码,觉得这个结构很冗杂,或者说不够明晰,可以模仿第五次的作业进行修改。
三、junit的心得体会
在一开始笔者在认真写junit,但在后续被覆盖率束缚住后,相较于正确性,或许更注重于那个百分比(悲)。
junit确实可以很好地去检查你所写的每个模块,但这是途径,怎么去构造数据去检查,才是重点。在书写时,大部分的情况其实在写代码时便已经考虑到,在写junit时也为跳脱出来,很可能是无效的。所以很多时候其只是去检查是否出现粗心错误,而很少能检查出是否是逻辑错误。
这也反应了笔者的全面思考能力仍有所欠缺,对于很多情况的边界等思考不足,也希望在其他调试程序时能有所改进。
四、心得体会
- 代码量不断增大,多次迭代,对于每一次的要求之高,一旦一次出错,在后面它总会显现,而我们在做项目工程时也是如此,不断迭代,因此对于每一次的测试与书写一定要做到细致入微。多情况考虑,考虑好实际情况的边界值。
- 从面向过程编程到面向对象编程(
面向测试编程),我觉得还是很有意思的,给我一种特别模拟真实情形的感觉。我们在写的时候,那些对象就是我们要去处理的,他们的私有属性不能动,通过方法去改变调用,联想我们平常玩的游戏或者软件也是这样。 - 对于个人代码能力的提高,当然这不是算法方面的,而是细节或者调试处理方面的,面对千行代码,如何发现一个小错误,痛并快乐着。
五、课程建议
1、建议对一些专有名词增加更多的例子,比如后面的模式,虽然学习了,还是觉得有点抽象模糊。
2、适当提高课程学分,或者降低工作量,因为作为一个pre课程,认为在前八周和计组一起,还是较为阴间,希望适当优化课程结构。