2025 BUAA OOPre课程总结

胡静伊-24373125 2025-11-15 19:02:10

架构设计和屡次迭代考虑

第二次作业

创建 Main，Adveturer，Bottle，Equipment类
其中读取和调用类直接在Main里面实现，此时Main只有45行
第三次作业
新增加了Spell类，并创建HealSpell、AttackSpell子类
创建Bottle的子类HpBottle、AtkBottle、DefBottle、ManaBottle
携带与否，我选择在子类中添加属性boolean isTake，这样非常方便，删除物品时只需要删一次。
因为Main爆行数了，于是把各个操作都分出来了各自的类，调用时传参数Scanner in和ArrayList<Adventurer> adventurers，现在看起来很鸡肋（）
嫌弃每次在ArrayList里面遍历找某个id的物品很麻烦，于是写了一个静态方法find，每次只需要给find传参数ArrayList<T> a，String id和Function<T,String> getId就能返回查找到的对象。
这里实现的use和输出类型我选择在各个子类中具体操作，好处是调用的时候不需要再分类别。
第四次作业
无迭代
第五次作业
创建Equipment类的子类Armour和Weapon类，并创建Weapon类的子类Sword和Magicbook类
因为携带Bottle要记录放入顺序，放弃 isTake的写法，改成LinkedList<Bottle> takeBottles
从第四次作业提供的源代码得到了启发，将所有操作类都写成一个Solver类，并把每个操作写成方法，好处是管理方便，也不需要传参。
发现了好用的HashMap，舍弃ArrayList，使用了HashMap，方法find也删去了。这里的fight和bi操作我都在Adventurer中实现了，并没有外包工厂或者接口。
第六次作业
我选择在Adventurer类中加Adventurer father和ArrayList<Adventurer> sons来表示直接的雇主和雇员，这样每个Adventurer都是树中的一个节点，寻找上下级也很方便，我并未模仿OO那篇推送中的接口示例，因为我觉得没有很明显的优点，作为雇员和雇主的只有Adventurer一种类，接口比较适合多样化的类别管理。
援助事件直接在Adventurer中实现
第七次作业
这一次在Solver类中写了个迭代方法relate，具体操作为，给每个relate方法传Adventurer father和String input（如果没有father则传null），然后在input中找到开头的人名b，将其和father绑定父子关系，并把人名后面的括号里面的内容（如果有括号的话），按照逗号一一分割传给下一个relate（下一个relate的father就是b）。
目前而言，我的架构十分简单明了，只要能向下承包的都向下承包，尽管大部分实现的具体内容都在Adventurer中，没有任何接口和工厂，我的Adventurer类也一共只有400行
使用JUnit的心得体会
我觉得这个测试方法的作用有限，如果已经定位了错误的位置，那么只是观察代码很容易就能发现bug；如果没有发现bug的位置，那么每个地方都要写测试和断言，还要精心设置一番数据是一件非常麻烦的事情。还不如一次性设计所有功能的输入数据，再根据实际结果和预期结果的对比发现bug的位置来的方便。并且有时候bug的出现是十分巧合的，并不是单次操作错误，而是一种连锁反应，Junit只能测试单一功能没有出错（也有可能是我Juit写的不好）。
学习OOPre的心得体会
我认为这节课非常有价值，是可以让人学到真东西的课堂，自由度也到位（因为课程组推荐的方法我很多都没用···）。从面向过程编程过渡到面向对象编程，原本一个十分复杂和体量庞大的代码和内存管理，在巧妙运用了类与对象的架构之后，就变得井井有条，可读性，维护性，扩展性都变得非常友好。而且这种方法自然，对象，父子，工厂等设计贴近现实生活的结构，让程序员理解起来更加容易。
对OOPre课程的简单建议
后期的各种新架构比如接口和工厂，希望举一些更能体现该架构优点的例子，并且和不使用该架构的例子进行对比。在写作业时我没有感觉到就作业而言有些新架构有什么优点（可能是作业任务还不够复杂多样的原因，但是希望也说明清楚）