2025—OOpre学习心得

满翔宇zc061026 2025-11-05 13:14:26

1.代码架构

1.1 实例类

（由于用的是社区版，没法直接导出类图，就手绘了）

其中Adventure类作为最核心的类，下面管理药水，法术和装备。药水下有四个子类，分别对应四种类型，装备同理。每个类中实现对应的功能，对应指令的实现只需在Input类中解析输入完后，调用相应方法即可。

1.2 输入解析类

其中Input类负责解析输入并调用相关方法；AdventureManage负责管理冒险者；Lexer，Paser及其子类进行递归下降法，负责解析lr的输入。

1.3 代码架构及调整

说实话，我的代码架构并不算很好，甚至可以说有点差，只在Bottle和Weapon这两个类里使用了继承，并未使用接口。对于可用物品我并没有单独创建一个类，而是在解析输入的时候进行分析，这也导致了我的Input类中，解析输入的方法超了行数，最后的代码风格分一直是80分。这一点是很不好的地方，在正课一定要吸取教训，多使用接口和继承，尽量把代码写的简洁。

我这几次迭代开发中，我重构了一次代码。在原先的代码架构中，我将输入解析放在了MainClass中，但是由于junit不算主类，当时写的代码总行数又不多，导致我的junit覆盖率较低。于是当时我进行了一次重构，新增了Input和AdvertureManage这两个类，前者负责解析输入，后者负责管理（如增加，查找）冒险者。这样，我的主类唯一的作用就是作为程序入口，通过对上述两个类建立junit，就成功提高了覆盖率。

2.JUnit使用心得

对于junit，虽然这次仅很有限的使用了这个功能，但我已经察觉到了这个功能的重大意义。通过编写多个测试程序，并通过assert()直接进行判断，可以非常方便的大致判断程序正误。我们可以编写基本和易错的测试点，一次性判断正误，而无需麻烦的手动输入。同时，对于迭代开发或者程序的修改，在每次修改后可以直接使用junit来检查此次修改是否影响了程序先前的正常功能，节省了大量检查时间。

对于迭代作业，我主要是编写了Input类的junit，即构造测试点，尽可能涵盖所有情况，包括各种细节和易错点。同时，为了增加覆盖率和下次开发，对类似Adventure类等方法较多的类，单独创建测试类，对其中的方法进行单独测试。尤其是本次没有使用，但后续可能会用到的方法，确保代码正确。

3.OOpre学习心得

总的来说，我对面向对象编程的体验只有一个字——爽。在度过了前两次作业的适应期之后，我发现用面向对象的方法写程序实在太爽了，根据对象创建对应的类，在类中实现所有相关方法，在外部直接调用即可。这种写程序的方式真的很有趣，尤其是在idea这样一个功能强大的IDE里，每次做oop作业感觉都是种享受。

在过渡期，我刚开始确实没有完成思维上的转变，这一点从在主类中写一大堆东西就可以看出来。面向过程是从头开始，一步一步来，完成目标；面向对象则是分析有多少种对象，每一步是对哪个对象进行处理，需要时只需直接调用。相比于前者，面向对象采用了模块化的编程思维，实现与某个对象相关的功能时，只需调用该模块中对应功能即可。这种方法可以提高程序的正确性，只需确保每个模块正确和逻辑正确。并且提高了程序的可扩展性，可以非常方便的实现新的功能。而且还使程序更加安全，每个类内部的的变量都是不可以被外界直接修改的。总的来说，面向对象可能在直观性上稍微差了一点，但是会更加适合大型程序的编写和软件开发。而我个人感觉这种方法编写会更令我安心，也会让我更想要去写程序。虽然听说oo正课比较难，但我已经开始期待了

再说下checkstyle吧，还记得第一次作业写完后调checkstyle调了快一小时，当时还以为每次都需要这样，但是在第三次第四次作业左右，我就发现我已经养成了良好的代码编写习惯，写代码时自动就带上了空格，换行之类的符号，每次最后只需要调整几个地方就可以了。我觉得通过这种checkstyle的方式，可以倒逼我们养成一个良好的代码风格，包括对行数的限制，其实也包含了面向对象的模块化思想，不允许一个方法行数太多，实现的功能太多，这样太容易出错。应该将其继续拆分，在不同类中实现各个细分功能。

总结一下，我认为这次oop的学习还是很有意义的，养成了面向对象的思维方式，学会了checkstyle和junit，虽然可能对于java语言的了解可能还不是很深，但是基本方法都已掌握，在oo正课中学习了java语言相关内容后，可以直接上手写代码，而不用为checkstyle和junit犯愁。同时，也有了迭代开发相关经验，为oo正课保驾护航。所以，不管是从哪个方面来说，oop都是一门很有价值的课，而且第九周结束，还不会影响期末，真是太好了（笑）