OOPre课程反思总结

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课程，认为在前八周和计组一起，还是较为阴间，希望适当优化课程结构。