OOPre的学习心得

[岳渊源-24231220]

面向对象先导课学习感悟

一、架构说明

1. 架构设计概览

1.1 MainClass

职责：程序入口，读取输入指令并调用 Guild 执行。

关键行为：

读取指令总数n

逐行解析指令并存入 ArrayList<ArrayList<String>>

调用 Guild.execute() 执行每一条指令

1.2 Guild（指令调度中心）

职责：解析指令类型并调用对应处理方法。

关键行为：

根据指令首字段（如 "aa", "ab", "fight" 等）分发到具体方法

维护所有冒险者列表 adventurers

处理战斗、雇佣、物品使用等复杂逻辑

1.3 Adventurer（核心实体类）

职责：代表一个冒险者，管理其状态、物品、法术、雇佣关系等。

属性：

基础属性：hitPoint, atk, def, mana, money

物品系统：ownedItems, carriedWeapon, carriedArmour, carriedBottles

法术系统：spells

雇佣关系：employer, employees

关键行为：

装备/卸下物品（takeItem）

使用物品/法术（通过 Usable 接口）

战斗逻辑（物理/魔法攻击）

雇佣关系维护（添加/移除雇员、判断上下级、盟友）

生命值变化触发援助机制（notifyEmployees）

1.4 物品体系（Item 及其子类）

 1.4.1 Bottle 系列（药水）

HpBottle：恢复生命值

AtkBottle：提升攻击力

DefBottle：提升防御力

ManaBottle：恢复法力值

特点：使用后即消失，效果一次性

 1.4.2 Equipment 系列（装备）

Sword：武器，提升攻击力

Armour：护甲，提升防御力

Magicbook：魔法书，用于魔法攻击

特点：装备后持续生效，可替换

 1.4.3 Spell 系列（法术）

HealSpell：治疗目标

AttackSpell：攻击目标

特点：消耗法力值，可重复使用

1.5 接口设计

 1.5.1 Usable

作用：统一所有可使用物品（药水、法术）的行为。

方法：

java

int[] use(Adventurer user, Adventurer target)

 1.5.2 Employer / Employee

作用：定义雇佣关系的双向接口，支持上下级通信。

方法：

Employer：添加/移除雇员、广播通知

Employee：设置雇主、响应雇主受伤

1.6 Factory（工厂类）

职责：统一创建各类物品，支持 bi 指令。

方法：

createBottle()：创建药水

createEquipment()：创建装备

createItem()：通用创建方法

1.7 雇佣关系系统

实现位置：嵌入在 Adventurer 类中。

关键行为：

判断上下级关系（isSuperiorOf）

判断盟友关系（isAllyOf）

递归收集所有下属（getAllEmployees）

生命值低于一半时触发求助（notifyEmployees）

1.8 战斗系统

实现位置：Guild 类中的 doFight 及相关方法。

类型：

物理攻击：基于攻击力与防御力差值

魔法攻击：消耗法力，无视防御，可群体攻击

特点：

受雇佣关系约束（不能攻击上级）

击杀后转移金币与物品价值

2. 整体架构思路

整个系统以 Adventurer 为核心，围绕其状态、物品、法术、雇佣关系构建了一套完整的冒险者模拟系统。通过 Guild 类统一调度指令，Factory 类统一创建物品，Usable 接口统一使用行为，实现了高内聚、低耦合的设计。雇佣关系系统通过接口 Employer/Employee 实现双向通信，并在生命值变化时触发救援机制，增强了系统的交互性和真实性。

3. 迭代亮点

工厂模式：统一物品创建，支持动态扩展

接口抽象：Usable、Employer、Employee 等接口明确职责，便于扩展

递归关系处理：雇佣上下级判断、下属收集等使用递归实现，支持多层级关系

事件驱动：生命值变化自动触发援助机制，体现观察者模式思想

二、学习junit的心得

 1.测试数据构造与组织策略

在JUnit测试实践中，我深刻体会到合理组织测试对象的重要性。预先实例化共享对象能显著提升测试效率，如在测试Adventurer类时，可以在@Before方法中初始化多个冒险者实例，供后续多个测试方法复用。这种做法不仅避免了重复的对象创建开销，还能确保测试环境的一致性。

对于涉及输入操作的方法测试，字符串模拟输入流是极为有效的技巧。通过构造符合格式的字符串并包装为Scanner对象，可以精准控制测试输入，完全隔离对外部资源的依赖，实现纯内存化的测试执行。

 2.测试用例设计的层次化思维

测试用例设计需要分层递进的逻辑思维。对于具有执行顺序依赖的指令序列，必须构建完整的测试前置链。例如测试雇佣关系时，需要先创建冒险者实例；测试解雇功能时，则需在雇佣关系建立的基础上进行。这种层次化的测试结构确保了每个功能模块在正确的上下文中被验证。

在代码复用方面，我认识到提取公共测试逻辑的价值。特别是在测试同一方法的不同分支路径时，通过参数化测试或提取辅助方法，可以大幅减少重复代码，提高测试套件的可维护性。

3.覆盖率驱动的测试完备性

JUnit测试的质量很大程度上取决于覆盖率目标的全面性。基础的Class和Method覆盖率只是入门要求，真正的测试完备性体现在Line和Branch覆盖上。

分支覆盖尤其需要精细设计。每个条件判断都应覆盖True和False两种路径，对于复合条件表达式如A&&B，必须构造四种测试场景：(A假,B假)、(A假,B真)、(A真,B假)、(A真,B真)。只有穷尽所有分支组合，才能暴露潜在的边界情况缺陷。

测试数据的构造应当兼顾典型性与边界性。在满足输入合法性的前提下，需要设计包含正常值、边界值、特殊值的多样化数据集，确保程序对各种有效输入都能正确响应。

4.测试驱动开发的工程价值

JUnit天然契合测试驱动开发(TDD) 模式。先编写测试用例再实现功能代码的开发流程，强迫开发者在编码前就明确接口规范、功能预期和异常场景，从源头上提升了代码质量。

在团队协作环境中，自动化测试套件构成了持续集成的安全网。每次代码提交后自动运行的测试不仅增强了集成信心，还为核心功能的稳定性提供了可靠保障，大大降低了回归缺陷的风险。

5.模块化测试的设计原则

编写测试代码时需要坚守关注点分离原则。每个测试模块应聚焦于单一功能单元的正确性，避免过度测试关联功能。例如测试AttackSpell时，只需验证该法术本身的伤害计算逻辑，而不应涉及Adventurer使用法术的完整流程。

这种高内聚、低耦合的测试设计理念，确保了测试套件的可维护性和可读性。只要每个独立模块的功能正确，通过组合这些模块构建的完整系统自然就能正确运行，这正是面向对象思想在测试领域的完美体现。

 

三、学习OOPre的心得体会

面向对象先导课程的学习是比较痛苦的，特别是和计组一起进行。面向对象先导课确实让我对编程有了新的认识。和计组一起学的时候，最大的感受是思维方式上的冲突——一边需要理解硬件的具体实现，一边要适应面向对象的高度抽象。

第一次接触迭代式作业，最后的结果是一个很大的工程，之前从未写过这么大的文件，对菜鸟而言真是生命拔节的痛苦。第一次做迭代式作业，每个阶段都在原有代码基础上添加新功能。这种开发方式让我意识到，代码不再是写完就丢的一次性产物，而是需要持续维护和扩展的资产。之前写C语言更多是解决眼前问题，现在必须考虑后续迭代的可能性。比如设计一个类时，不仅要满足当前需求，还要思考它未来可能如何被复用或扩展。

而且在这个学习过程中接触到了很多比较复杂的工具，比如idea、gitlab等等，让我从天真无邪的萌新稍微的显得专业了一丝丝······这些工具不仅提高了效率，更重要的是它们改变了工作流程。学会使用专业的开发工具，意味着开始以更系统化的方式思考软件开发。

新接触了Java语言，深刻的体会到了他与我之前主要运用的C语言的差别，不知是不是checkstyle和问题的复杂度强迫着我写出更优美的程序的缘故，感觉Java要比C语言清晰许多，读这个游戏程序代码的过程好像在看一部英文小说。Java和C的差异不仅体现在语法上，更体现在编程范式上。C语言里，数据和函数是分离的；而在Java中，数据和操作数据的方法被捆绑在一起。这种封装性让代码结构更清晰，但也需要更强的设计意识。CheckStyle这类工具强制我们遵循编码规范，起初觉得极其的束缚啊，后来发现规范的代码确实更易读、更易维护。

面向对象的思维也是一种全新的体验，从刚刚接触这门课的时候，这些思想和概念还是非常晦涩和抽象的，但是在运用的过程中慢慢有了新的理解。写C语言面向过程的程序时感觉自己好像是一个数据，化身一个小球在一个轨道上流转，写Java面向对象的程序时感觉自己好像上帝一般，各种的类都是我手中的提线木偶由我摆弄。面向对象的核心思想——封装、继承、多态，刚开始确实很抽象。直到在作业中实际应用了继承 hierarchy，才理解到这种设计如何减少代码重复、提高可扩展性。写C程序时，我们关注的是“怎么做”的过程；而在Java中，更多思考的是“是什么”以及它们之间的关系。这种思维转变需要时间，但一旦适应，处理复杂系统时会更有条理。

OOpre课程充分体现了6系课程设计的专业性和严谨性，是一门非常实践、非常新颖的课（相对于大一的课程而言）。当然，更是一门充满挑战的课程，让我感受到了6系的氛围呜呜呜。不过在这个学习过程中，可以看见讨论区和微信群里大家激烈的讨论和大神的分享，能从同学的身上学到很多，也更理解了世界的参差······讨论区和群里的交流让我看到了不同的解题思路。

对下学期要到来的面向对象正课充满了紧张，寒假了一定要再准备准备。这门课确实比大一的课程更接近真实的软件开发。它不再只是解决孤立的算法问题，而是要构建一个有机的、可演进的系统。这种训练对思维能力提出了更高要求，但也为后续学习打下了重要基础。寒假的学习，我打算重点练习如何更好地进行类的职责划分和接口设计，这是我在先导课中感觉最需要加强的部分。

四、对课程的建议：

1. 建议系统能更完美一点，不要太多的bug，会很搞心态
2. 建议提交的次数和冷却期能更友好一点，给比较后进的同学更多的包容