OOpre课程总结反思

秦康-24371236 2025-11-13 00:32:35

作业架构设计

迭代过程与心得体会

最初迭代的时候还没有完全掌握java语法，只好借助ai完成作业，后面一口气把前三次迭代的作业全部重写（~~一口气写了四百多行代码真爽吧~~），边写边学了java的语法，开始慢慢了解到Java与C语言的不同之处。写的时候的最大的感觉就是通畅，Java把许多细节封装成函数，想用的时候直接调用，不用再像C语言那样关注代码逻辑的时候还要关注诸如数组下标之类的语法细节，这点确实相当爽，就感觉想到啥就直接写，很少有因为卡壳打断思维连续性的情况。另外我从学数据结构的时候就习惯在开发这就有点复杂的程序前先在纸上写一下伪代码，现在看来这的确是一个很高明的做法，有相当多同学的bug是出在忘记实现题目细节要求，但这些细节我都会在开发前在纸上写好，敲代码的时候就只需要翻译纸上的伪代码，也能保持时刻清楚自己在敲哪一块内容，再配合Java好用的类库，代码体验简直行云流水，在debug上的优势也很显著，我一向赞成最好的debug方法就是不写出bug，这一点保证代码逻辑清晰就不会出那种疑难杂症的bug，我遇到的bug大多是在一些小的细节上，比如 >= 写成 > ，中测过了的话强测也基本都能过。其实我遇到的最大挑战是在代码职责的分配上，要把哪些功能拿出来单独成类，每个类里又要承担哪些职责管理哪些数据，这也是我在oopre的学习中收获最大的，在初期迭代的时候我觉得最容易被绕晕的是数据之间的相互关系，但其实这些数据中又有非常明显的层级关系，我把adventurers的实现放在我的solver类中（我用solver类来实现控制逻辑），solver类也就负责处理冒险者之间的交互关系，而冒险者自己的事以及冒险者拥有的item就完全放到adventurer类中，我还定义了一个backpack类用于给冒险者装携带的物品。在迭代中我体会最深同时也是觉得最好用的一个编程思想是“单一职责原则”，我利用这个编程思想确定了我要把哪些逻辑作为一个方法，哪些逻辑不应该放在同一方法中，一个例子是我在代码中写了一个kill方法来处理冒险者击败别人时的逻辑，包括设置被击败者的isDead为ture，抢光被击败者的钱，将被击败者的上下级清空等，这种将死亡带来的全部操作打包的方式就直接避免了在use中只判定死亡而忘记爆金币的bug。另一个例子是我的所有的输出都由solver类完成，use方法之类的不会进行输出逻辑，而是在完成use之后把需要输出的string作为返回值一层一层往回传。

public void kill(Adventurer victim) {
        victim.setHitPoint(0);
        victim.setDead(true);
        this.money += victim.totalValue();
        if (victim.boss != null) {
            victim.boss.removeSubordinate(victim);
        }
        for (Adventurer subordinate : victim.subordinates) {
            subordinate.removeBoss();
        }
        victim.removeBoss();
        victim.subordinates.clear();
    }

迭代中另一个比较困扰我的一点是该如何确定哪些代码逻辑需要单独成类，哪些只需要作为一个封装的方法就好。我把自己的架构与博客里别的同学的代码架构进行了比较，发现主要是两个不同：1.继承使用较少，同学们基本都给bottle类写了四个子类，给equipment类写了三个子类，但我就只写了一个item类作为bottle类与equipment的子类。2.别的同学拆分出了更多的类，比如写observer类的，写fight类的，写aid类的，写parse类的，但我的类拆得没有这么细，很多逻辑都直接封装为方法放在adventurer类里。个人感觉虽然在这次oopre的作业里继承出那么多子类没啥用，但如果还需要对各种bottle的功能进行迭代的话拆分出这些子类就很有必要了，另外关于代码逻辑单独成类的问题我还是有点不清楚，个人觉得将那些本来聚合度很高的代码拆出来单独作为一个类有些过度设计？我也不知道，到时候看看参考代码是怎么写的。

Junit心得体会

系统性地编写和分析这些JUnit测试代码后，我体会到JUnit的意义首先体现在构建质量信心上。如adventurertest中上百个用例对角色属性、战斗、物品交互等进行了全方位验证，形成了一个安全网，确保任何修改都不会无意破坏现有功能，这对于复杂系统的迭代开发至关重要。同时，JUnit也驱动了更好的代码设计。为了便于测试，代码必须模块化、低耦合，这迫使开发者思考如何设计清晰的接口和依赖管理，例如通过setUp方法初始化测试环境，使得SolverTest等复杂场景测试成为可能。测试代码本身就是最生动的文档，它用具体实例清晰地说明了每个类和方法的行为预期，比任何文字描述都准确。不过感觉写junit最难的就是编测试用例，发觉自己被网站的测评机惯坏了