2025OOpre学习心得

[尚锦程-24231214]

OOPre课程学习总结：从过程到对象的编程思维转变

作业架构设计与迭代演进

初期架构（1-3次作业）：开始时采用了比较简单的类结构，主要包含Adventurer、Bottle、Equipment等基础类。这时候更多是"有什么就建什么类"的思维，缺乏整体规划。

中期调整（4-5次作业）：随着功能增加，引入了Factory工厂类来统一创建物品，这是第一次有意识地使用设计模式。同时为装备系统建立了继承体系，Sword、Armour、Magicbook都继承自Equipment基类。

后期完善（6-7次作业）：最大的架构变化是引入了Employer类来管理雇佣关系，以及Parser和Lexer来实现递归下降解析。这时候开始真正思考类之间的职责划分和数据流向。

关键设计决策：

• 将雇佣关系管理独立成Employer类，而不是放在Adventurer中

• 使用工厂模式创建物品，避免在业务逻辑中直接new对象

• 为lr指令专门设计了解析器组件，保持主逻辑清晰

JUnit测试实践体会

从第四次作业开始系统使用JUnit，最大的感受是：测试不是负担，而是保障。

测试策略演进：

• 初期：只测试正常流程，忽略边界情况

• 中期：开始关注异常测试和边界值测试

• 后期：为每个新功能优先编写测试用例

最有价值的发现：在实现雇佣关系检查时，通过测试发现了业务逻辑顺序问题——应该在检查物品存在性之前先检查雇佣关系。这个bug在手动测试时很难发现，但通过单元测试很容易定位。

测试覆盖率的意义：90%的方法覆盖率要求促使我不得不为那些"觉得不会出错"的方法也编写测试，结果确实发现了一些隐藏问题。

面向对象编程的学习心得

最大的转变是从关注步骤到关注对象。

过程式思维的惯性：前两次作业时，我还在用C语言的思路，想着"先做什么、再做什么"，把Adventurer类写成了一个大杂烩，里面充满了各种if-else。

对象思维的觉醒：第三次作业时开始真正理解"对象是自己的主人"这个概念。每个对象应该负责自己的行为和数据，比如：

• Adventurer自己决定能否使用某个物品

• Employer独立管理所有雇佣关系

• Parser专注解析语法结构

封装的价值：通过将雇佣关系检查封装在Employer中，主程序只需要关心"能不能用"，而不需要知道"为什么不能用的具体逻辑"。这种职责分离让代码更易维护。

多态的应用：在装备系统中，虽然Sword、Magicbook的计算方式不同，但通过统一的getAtk()接口，战斗逻辑可以一致处理，这是面向对象最优雅的地方。

对OOPre课程的两点建议

1. 希望提供更多架构演进的示例：现有的指导书主要讲功能需求，如果能展示一些从简单到复杂的架构演进案例，对理解面向对象设计会更有帮助。

2. 增加代码评审环节：同学之间互相review代码，能够更直观地看到不同的设计思路，这种学习比单纯看理论更有效。

通过这门课程，我不仅学会了Java语法，更重要的是建立了面向对象的设计思维，希望能够在后序的课程中有更多的收获