OOPre课程总结与学习心得

[吕思瑶-24373061]

OOpre课程总结

作业架构

架构设计

第一层框架:
设有Adventurer，Bottle，Equipments，Spell四个类别
另外设有Command类处理输入解析，设有Lexer类处理最后一次迭代的递归下降问题。

第二层框架：

• Adventurer
  --->Employee与Boss接口，处理雇佣、救助、冒险者关系判断的功能
• Bottle
  --->AtkBottle,DefBottle,HpBottle,ManaBottle四个子类，通过继承提取出子类的共性
  --->同时设置有act接口，用于实现不同药水对于冒险者的不同功能
• Equipment
  --->Sword,Armour,Magicbook三个子类，通过继承提取出子类的共性
  --->同时设置有act接口，但只对于Magicbook进行了接入，Sword产生的攻击效果直接在Command中进行了实现
• Spell
  --->HealSpell和AttackSpell两个子类，通过继承提取出子类的共性
  --->同时设置有act接口，用于实现不同技能对于冒险者的不同功能

递归过程：

第二次作业

--->新建冒险者
--->给冒险者增加、删除药水瓶或装备
当时输入的内容也很简单，直接简单的通过输入进行读取，没有用到课程组提供的输入解析功能，思路上也基本是按照面向过程来实现，感觉像是用java在实现c语言。

（现在看来好简单啊。)

第三次作业

--->增加法术功能，Spell类
--->增加背包功能，当时对物品增加属性istaken，通过0/1进行判断是否在背包内；使用arraylist管理拥有的药水和装备

进行第一次重构，主要是增加了Command输入解析类，同时在Command中实现findAdventurer()方法，查找指令中被操作的冒险者，大大缩短Command方法的长度。

第五次作业
--->用linkedList对于背包进行管理，通过遍历查找物品是否在背包中
--->细化装备属性。同时对bottle、spell类进行重新处理，确定用父类子类的方式处理bottle、equipment、spell，这个时候对物品的管理较为清晰。
--->引入act接口、fight接口分别处理使用药水以及战斗的问题
--->引入金钱系统
强测爆了，只有20分，主要问题是在处理移除装备的时候忘记移除Armour，且对于属性的更改有问题；

第六次作业

--->使用hashmap管理冒险者，使用hashmap管理装备（名称与属性对应）

--->修改act接口，把fight和act合并为act接口，使得对于冒险者HitPoint的修改基本统一
--->引入雇佣者关系，主要包括hire、判断同盟以及救助，使用Arraylist进行管理
输出的时候少打了空格；在递归救助的时候逻辑出了问题，没有记录”下属的下属救助”的情况，后进行修改。

第七次作业
--->引入递归下降，主要是使用模板进行设计

总结：

除去最后一次递归下降的内容，在设计中我使用Bottle、Equipment、Spell管理子类，管理各种物品技能的属性；并且主要使用Act接口管理对冒险者的攻击、治疗效果，主要使用Boss和Employee接口完成对冒险者雇佣关系的梳理。
现在写来，感觉整体的框架还算比较清晰，但是仍然存在一些考虑不足、或者是封装不到位、代码冗长的情况，目前有记忆的是这几点：
①在指令处理的过程中，一开始没有把输入读取和操作解析分开来，导致Command方法很快爆了行数，后续把输入和解析做了区分，但进一步可以之前优秀代码借鉴，把不同的指令分类进行处理，应该会更好的封装、也更加清晰。
②在处理Act接口的时候，虽然已经在迭代过程中把Bottle和Spell产生影响由两个接口合并为一个，但没有把所有的与冒险者体能的修改都包括进去，比如Sword就直接在Command类别里面进行了操作，导致批量修改或者查看的时候逻辑不统一，封装可以更好。
③在处理冒险者关系上，当时那周做作业时间紧张，导致了一些冗余代码的出现，比如对于判断雇佣者关系和判断救助时候分别写方法，使用了两次类似的dfs，总感觉可以合并为一个。

使用JUnit的心得体会

首先，我能意识到Junit的作用，也确实通过自己编写代码在中测前检查出来了一些问题、检查出中测没有检查出的问题，比较有成就感。

但是，对于生成测试数据等内容我的体会不深，很多时候就是用中测数据、自己想一些、用大模型辅助生成一些，基本上是凑上啥用啥，没有很多刻意的设计，总感觉并没有发挥出Junit的许多功力。

学习OOPre的心得体会

在OOPre的学习中，的确体会到了从面向过程变成到面向对象编程思路变化。其实在第2、3次迭代的过程中，我好像还没怎么意识到这件事，还觉得自己就是根据指令一条一条完善代码，当时简单认为“类≈结构体+函数”的形式，试图通过类比c语言来学习。但是在后面，尤其是欣赏了一些大佬架构以及随着课堂内容更加深入，我好像更明白了面向对象“封装、继承、多态”这样的思想，也发现很多时候自己真正做完了作业，决定其实没有一开始想象的那么难（我觉得是因为自己脑子中最直接的想法还是面向过程，但是在实现过程中逐渐通过面向对象的操作化简了过程），能调用之前封装好的内容真爽。

另外很重要的一点，就是体会到了“测评通过≠正确”这一点。在之前程序设计和数据结构课程中，主要目的就是通过测评，有时候有一种“交一发吧万一过了呢？”的侥幸感；在oopre中深刻意识到自己检查的重要性，比较中测过了还有强测（中测数据点真的好弱。），强测过了也可能在下一次迭代中发现遗留问题，哪怕现在测评告一段落也很难说自己的代码真的没有问题。这种体会让我从纯粹“答题”的考生心态产生了一些转变，关键在于自己要对自己代码的正确性负责，感觉这是面向未来参与更大体量开发的一个重要铺垫。

对OOPre课程的简单建议（不多于两条）

1.在学习过程中对于架构设计进行更多的指导。我觉得虽然每次课程最后老师会点拨一下本周作业的内容，但有时候仍然觉得很蒙。尤其是oopre的迭代性质，使得上次作业不好的设计极大可能被保留，后续不好弥补，或者说逐渐使得自己的代码离“优雅”、“好的架构”越来越远，自己可能意识到但并不明确具体的差距，也不知道从何入手去修改。感觉如果可以在中期之类的时候公布一些优秀代码架构，会使得自己更加明晰一些。还有一些具体实现的细节，虽然肯定不能照抄别人的，但如果不是收到大佬启发，我自己真的不太知道如何能想到、学到这些内容。
2.对于测试代码的编写进行更多指导。希望可以对如何编写好的测试代码、如何造数据、如何“自动化测试”相关的内容给出更多的指导，虽然现在确实有指导，但周围的反馈来看，有相当一部分同学是拿中测数据或者很简单的数据”为了通过测试“而写Junit，并没有很好的锻炼自己的能力，或者说不知道如何去锻炼自己的能力，感觉在oo正课可能会有点艰难。