学习OOP走过的那些弯路——BUAA2023秋季学期面向对象先导课程总结

BUAA2023秋季学期面向对象先导课程总结

本文是一篇以climber心态写出的文章~

短短半学期的OOpre可谓令人印象深刻，在学习过程中，笔者经历过不熟悉JAVA语法的困惑，熬夜为强测debug，忍受不了代码风格而重开 重构，难以决定代码架构等问题。所幸关关难过关关过，顺利完成OOpre的任务，也算为OO的学习做了一些准备。

截至第七次作业结束，代码中依然存在许多设计理念问题，就像OO的学习之路仍然漫长，聊加讨论，望有启发。

---

1.作业架构设计及调整考虑

在hw4及之前，我简单的在main函数中堆叠输入与方法，导致输入管理混乱，方法臃肿。在hw4中体会到了这种混乱的后果，以及学习了hw5示例代码的写法后，本人痛心疾首的进行了重构，在demo中进行了统一输入管理，梳理的方法调用逻辑，虽然代码量有所增加，但可读性与清晰性反而增加。

而在代码主体部分，我没有实现Bag类，而是简单的为Adventurer添加容器，自我感觉这样的实现相比单独实现类更为简便。且bag与adventurer高度关联，不需要分离对待。

图中省略由Bottle，Equipment扩展出的一些子类，其实现逻辑与super类并无明显区别。

通过一次次开发，我得到的经验是，如果担心在迭代过程中实现的代码逻辑上有所冲突，就一定要注意对逻辑进行统一规定，始终遵守。最简单的就算模仿现实生活中的实现逻辑。比如携带的物品要不要背包和仓库里存储两边，针对使用药水是将capacity设为0还是增加属性，后续迭代中的扩展可能必须与这些实现细节相吻合，故必须做出规定，实现时必须清晰。有利于后续的扩展或调整。

---

2.使用Junit的心得体会

我在使用Junit时，感觉有一种插桩检测的感觉。

使用Junit，做到断言检测是关键。在test部分构建好想要测试的数据之后，应对所有需要关注的点进行断言检测，很多逻辑错误就在一些不引人注目的点上。如第七次作业中，将删除方法改为卖出方法后有没有正确区分卖出和使用丢弃的行为。我的朋友在debug时信誓旦旦的保证他完成了正确区分，后来发现他在某些场景依然没有正确区分.（此处鸣谢不愿透露姓名的rj同学~）

当然有很多错误是难以想象的，比如我在实现“检测冒险者被攻击的战斗日志时”，为每段Log存储了参加战斗的冒险者名字，但是这些名字是以字符数组存储的，一旦两个字符数组完全一样，则取到的是第一个字符数组。在ArrayList中本不存在这种问题，但字符类型较为特殊。

类似问题如果单凭瞪眼法可能难以发现，但如果能通过Junit先发现问题出现的区域，再进行可能原因分析，就能事半功倍。

---

3.学习OOpre的心得体会

老实说，对于没有任何基础的我来说，进入大一以后，从学习c语言，到学习一些标记语言，再到学习面向对象编程，很多理解不断被更新，很多今天奉为圭臬的理念明天就被放弃。有时候会有些不适应，但在实践中能不断发现这些新理念的可贵之处。

所以我有一些心得体会，比如要勇于重构，而且重构要趁早，码少不努力，码长徒伤悲；比如要多想北海，要多想，先想明白了再下手经常以此为借口把写作业活动拖延到ddl；还有面向对象编程的一些理念，看似可以假装没学过然后强行实现一些功能，但实际上非常重要，在这方面仍有待提高。

虽然提前学习一下学长的博客能达到事半功倍的效果，但是亲手写出烂代码再亲自修改肯定印象更深刻吧x,以后就不会心存侥幸放松约束了X_X

OOpre结束了，OO还会远吗。我祝大家好运，希望大家也祝我好运 。(别hack我QAQ)

---

4.对OOpre课程的简单建议

相信很多有志之士是勇于重构的，但是苦于没有时间，其实十一假期是个不错的时机。但是就课程进度来说，此时作业的长度还没有让大家意识到自己代码中的问题，且还没到hw5，一些同学还没看过一些很有水平的代码（比如我）。希望课程组有条件的话可以调整一下进度，为大家重构投入更多精力创造更有利的条件。
第二点：强测扣分能不能和奖励分抵消啊球球