309
社区成员
发帖
与我相关
我的任务
分享初期架构(1-3次作业):开始时采用了比较简单的类结构,主要包含Adventurer、Bottle、Equipment等基础类。这时候更多是"有什么就建什么类"的思维,缺乏整体规划。
中期调整(4-5次作业):随着功能增加,引入了Factory工厂类来统一创建物品,这是第一次有意识地使用设计模式。同时为装备系统建立了继承体系,Sword、Armour、Magicbook都继承自Equipment基类。
后期完善(6-7次作业):最大的架构变化是引入了Employer类来管理雇佣关系,以及Parser和Lexer来实现递归下降解析。这时候开始真正思考类之间的职责划分和数据流向。
关键设计决策:
将雇佣关系管理独立成Employer类,而不是放在Adventurer中
使用工厂模式创建物品,避免在业务逻辑中直接new对象
为lr指令专门设计了解析器组件,保持主逻辑清晰
从第四次作业开始系统使用JUnit,最大的感受是:测试不是负担,而是保障。
测试策略演进:
初期:只测试正常流程,忽略边界情况
中期:开始关注异常测试和边界值测试
后期:为每个新功能优先编写测试用例
最有价值的发现:在实现雇佣关系检查时,通过测试发现了业务逻辑顺序问题——应该在检查物品存在性之前先检查雇佣关系。这个bug在手动测试时很难发现,但通过单元测试很容易定位。
测试覆盖率的意义:90%的方法覆盖率要求促使我不得不为那些"觉得不会出错"的方法也编写测试,结果确实发现了一些隐藏问题。
最大的转变是从关注步骤到关注对象。
过程式思维的惯性:前两次作业时,我还在用C语言的思路,想着"先做什么、再做什么",把Adventurer类写成了一个大杂烩,里面充满了各种if-else。
对象思维的觉醒:第三次作业时开始真正理解"对象是自己的主人"这个概念。每个对象应该负责自己的行为和数据,比如:
Adventurer自己决定能否使用某个物品
Employer独立管理所有雇佣关系
Parser专注解析语法结构
封装的价值:通过将雇佣关系检查封装在Employer中,主程序只需要关心"能不能用",而不需要知道"为什么不能用的具体逻辑"。这种职责分离让代码更易维护。
多态的应用:在装备系统中,虽然Sword、Magicbook的计算方式不同,但通过统一的getAtk()接口,战斗逻辑可以一致处理,这是面向对象最优雅的地方。
希望提供更多架构演进的示例:现有的指导书主要讲功能需求,如果能展示一些从简单到复杂的架构演进案例,对理解面向对象设计会更有帮助。
增加代码评审环节:同学之间互相review代码,能够更直观地看到不同的设计思路,这种学习比单纯看理论更有效。
通过这门课程,我不仅学会了Java语法,更重要的是建立了面向对象的设计思维,希望能够在后序的课程中有更多的收获