OOpre课程心得&总结

李思瑶-24371271 2025-11-06 21:53:15

写在前面

这篇博客应该是OOpre的最后一次作业了，也标志着我们在OO大陆的冒险将告一段落。作为一份作业，应该有的模块与对应的问题都会在里面有所回应，但私心而言，我也更愿将这篇博客作为这半学期以来种种体验的一次纪念吧。

关于架构设计

整体架构大概分为4部分：

输入处理相关：MainClass, Solver, parser, laxer
读入指令，完成对输入的初步处理，调用各个指令对应的方法
冒险者相关：Adventure, AdventureUtils
Adventure类实现冒险者相关的方法，包含物品管理、攻击与援助、雇佣关系等。
雇佣于援助:Employee, Employer,Tablet
实现雇佣关系相应的方法，包含雇佣关系添加与解除，冒险者援助等
物品与法术：Equipment, Bottle, Spell
Equipment, Bottle, Spell三类为主要物品与法术类型，三者下设具体的分类。

初步建立

第二、三次作业完成了对面向对象基本代码的编写，实现了药水瓶与装备类，并在之后的迭代中完成类型的细化，同时添加了法术的学习。同时第三次作业中完成了背包结构的建立。
这两次作业应该是我第一次接触迭代完成的作业，虽然指导书中有“考虑到每一次所写代码的可扩展性和可维护性”等言语的暗示，但在实现过程中还是有心无力。虽然在第三次作业中设计出背包类实现对物品的统一管理，但后续因为背包每种物品有对应的携带限额而显得有些冗余，最终还是删掉了。但看框架图的时候，如果有一个统一的packable类在Bottle、Equipment之上可能会更为清晰。现在回看，如果当初对类的方法设计或容器设计更为合理，也许可以更实用一些?

更进一步

第五、六次作业引入了设计模式，添加了工厂模式、观察者模式分别对应金钱系统和雇佣管理中的援助。金钱系统与雇佣关系的引入也带来了更为复杂的逻辑判断。对于这两次作业，我的解决办法是仔细读指导书，尽量准确理解逻辑关系之后再动手，为之后debug环节减少压力。
架构设计上，这两次作业也是我重构较多的两次，包括但不限于类的修改、函数接口的重新设计等。其中一部分是之前设计时未考虑到后续的需求，出错后重新更正，一部分是在编写过程中怀疑之前类设计的必要性，最后直接删去。
初次接触设计模式对知识理解还是不够深入，应用起来更多是照葫芦画瓢（感谢oolens，有很仔细的知识讲解和对应的代码样例，在课上点到为止的知识讲解之外让我见到了实际中的代码实现）。最终实现效果比起设计，不如说是将许多模块拼在一起，还是有些遗憾的。

最后

第七次作业涉及了递归下降和相关的问文法知识，是我个人认为最难理解的一部分内容。虽然oolens有相关的知识点讲解，但……
幸运的是课程组已经给出了很大一部分的代码，需要我们补全的很少。

关于Junit

虽然最初是在作业强制要求下被迫开始使用，但到最后也不得承认Junit虽然繁琐，但确实能有效帮助发现潜在的逻辑上的漏洞(~~当然是在认真对待的前提下~~)。
实际体验过程中，我感觉Junit像是让我们从最小单元开始检查代码是否有问题，并通过覆盖率帮助我们发现遗漏的情况。比起全局角度的样例构造，Junit更像是从底层开始，虽然繁琐，但更为专注。
说完优点，Junit测试也不免存在不足。停留单个方法层面的检查无法发现代码整体逻辑框架上的问题。如要发现代码整体逻辑上的问题，还是需要再仔细读指导书，尽量正确理解题目要求的前提下再在脑中盘自己代码执行的大逻辑，尤其看指导书中提醒的优先级、特判等内容自己的代码中是否对应处理。

从面向过程编程到面向对象

其实到现在为止，我并不敢说自己真正理解了什么是面向对象，只能说是在这短短半个学期的课程中欣赏也尝试了一种新的编程思想。虽然最初会小小抱怨代码的冗余，C短短一行就能完成的事还要单写一个方法，但随着迭代的深入，我渐渐意识到这种代码量的任务若还是沿用面向过程编程，或许初期会很快，但到后期很可能就会被繁杂的代码绕进去。
我理解中的面向对象像是在代码编写中加中间层，将任务层层分解，而每一层只专注于自己的任务，最后拼装组合实现目的。虽然分解的过程势必会让代码的模块增多，一眼望去好像很繁杂，但站在每一层看，结构都是极为清晰的。