作业集1~3的总结性Blog

一、 前言：

围绕“航空器配载与货运管理系统”这一真实航空业务场景，完成了三次递进式的迭代开发作业。分三个阶段逐步实现配载系统的核心功能，难度呈阶梯式上升，层层递进、环环相扣。本文将结合三次作业的设计思路、实现过程、遇到的问题及改进方向进行全面总结，梳理收获与不足，为后续编程学习积累经验。
（1）作业整体概述
作业集1：搭建基础框架，实现航班信息管理、货物装载与超载判断。核心需求是记录航班的基本信息（航班号、最大载重），按货物重量从高到低依次装载货物，输出装载信息、总重量及配载状态，重点考察面向对象的封装思想和简单排序算法的实现。
难度：个人感觉难度中等，题量中等，对于刚学封装的我来说还是个不小的考验

作业集2（多货舱）：在作业1的基础上升级，引入前后两个独立货舱，实现货舱的行列划分与货位管理，强化输入校验和货舱容量校验，新增货物按编号升序排序的功能，重点考察类的职责拆分、输入校验逻辑
难度：难度偏高，题量中等，多次检验一不小心就会踩进陷阱，多次修改后依然未能解决....

作业集3（载重平衡）：完成系统的完整功能迭代，新增旅客与行李管理模块，实现基于物理力矩的载重平衡计算（总重量、总力矩、实际重心、重心百分比），根据重心百分比判断飞行安全状态，输出标准化的载重平衡舱单，重点考察组合关系、依赖关系的应用、复杂公式的实现和业务逻辑的完整性。
难度：难度巨高，写得人都快抑郁了

三次作业的开发过程，是一个从“单一功能实现”到“多模块协同”，从“简单逻辑处理”到“复杂业务落地”的过程。每一次作业都需要在前一次的基础上进行扩展和优化，同时解决新的业务需求和技术难点。

二、设计与分析：

（一）作业1：

1. 核心需求与业务分析

作业1作为系列作业的基础，需求相对简洁但核心明确，主要包含三个核心功能：录入航班的基本信息（航班号、最大载重）；按顺序装载指定数量的货物（含名称和重量），装载后按重量从高到低排序；计算已装载货物总重量，与航班最大载重对比判断是否超载，并按指定格式输出结果。

2. 类设计与类图

本次作业严格遵循单一职责原则（SRP），将不同业务功能拆分到不同类中，避免职责冗余，具体类设计如下：

Cargo类：仅封装货物名称（cargoName）和重量（cargoWeight），提供getter方法，不包含任何业务逻辑，仅负责数据封装与访问。

Flight类：管理航班信息和货物装载逻辑，包含航班号、最大载重、已装载货物列表三个属性，提供添加货物、计算总重量、排序、判断超载等方法，不涉及输入输出。

Main类：负责程序主流程控制，接收用户输入、创建对象、调用方法、格式化输出结果，仅承担输入输出和流程调度职责。

PowerDesigner类图：

3. SourceMonitor 代码度量分析

为了客观评估代码质量，我使用SourceMonitor工具对作业1的代码进行了度量，具体结果如下表所示：

从度量结果可以看出，作业1的代码整体质量较好，结构清晰、逻辑简单，但在注释率方面存在明显不足，后续需要加强代码注释，提高代码的可维护性。

4. 设计心得与反思

作业集1作为我接触面向对象编程以来的第一个综合性作业，让我初步体会到了封装思想的意义：将货物的属性和行为封装在Cargo类中，将航班的管理逻辑封装在Flight类中，实现了数据与行为的分离，避免了代码的耦合。但也暴露了诸多不足：边界处理意识薄弱，未考虑极端场景；代码规范性不足；输出细节把控不到位，丢失格式分。这些问题为后续作业优化指明了方向。

作业集2：

1.核心需求与业务升级

作业集2在作业集1的基础上，对业务需求进行了重大升级。本次作业的核心需求包括：一是引入多个个独立的货舱，每个货舱有独立的行列划分（即货位），需要抽象出货位类管理货舱的位置信息；二是强化输入校验，对所有输入的数值（最大载重、货物重量等）进行合法性校验，若输入负数或超出合理范围，立即终止程序并提示错误；三是实现货物的精细化管理，每一件货物需要分配到指定货舱，且每个货舱的装载重量不能超过其最大载重，若超载则提示警告并终止程序；四是新增货物按编号升序排序的功能，输出时按货舱分别输出，且货物按编号从小到大排列。

2.类设计与类图

本次作业在作业1的基础上，新增了多个类，进一步拆分职责，严格遵循单一职责原则，使代码结构更加清晰、可维护。具体类设计如下：

Position类：抽象货舱的行列位置，仅负责封装货位的行号（row）和列号（col），提供getPosName方法，用于获取货位的名称（如“0-0”），职责单一，仅负责货位信息的封装与访问。

Cargo类：在作业1的基础上进行扩展，新增货物编号（id）和所属货舱（cabin）两个属性，用于区分不同货物和其所属的货舱，仍然仅负责货物属性的封装，不包含业务逻辑。

CargoCompartment类：新增类，负责单个货舱的管理，包含货舱ID（id）、最大载重（maxWeight）、货位列表（positions）、已装载货物列表（cargos）四个核心属性。提供的方法包括：添加货物、计算当前货舱载重、判断货舱是否超载、对货物按编号升序排序等。该类的职责是货舱的精细化管理，与Flight类实现解耦。

Flight类：在作业1的基础上进行扩展，新增货舱列表（cabinList），用于管理前后两个货舱，提供添加货舱、获取货舱等方法，不再直接管理货物，而是通过货舱对象间接管理货物，职责更加单一（仅负责航班整体信息和货舱管理）。

InputValidator类：新增工具类，负责统一处理所有输入校验逻辑，提供静态方法用于校验整数、浮点数的合法性（如是否为负数、是否超出范围），职责单一，仅负责输入校验，避免校验逻辑分散在各个类中，减少代码冗余。

Main类：负责程序的主流程控制，接收用户输入、创建货舱、航班、货物对象，调用相关类的方法完成货物装载和排序，按照题目要求的格式输出结果，职责与作业1一致，仅负责流程调度和输入输出。

PowerDesigner类图：


Flight类包含多个CargoCompartment对象，CargoCompartment类包含多个Position对象和多个Cargo对象，InputValidator类为工具类，被Main类依赖，Cargo类与CargoCompartment类存在关联关系。

3.SourceMonitor 代码度量分析

使用SourceMonitor工具对作业2的代码进行度量，具体结果如下表所示：

从度量结果看：代码结构清晰、复杂度控制优秀，整体质量良好。
唯一短板是 0% 的注释率，补充关键注释后，代码的可维护性会大幅提升。

4.设计心得与反思

作业2的开发过程，体会到了单一职责原则在实际开发中的重要性。通过将输入校验逻辑拆分到InputValidator工具类，将货舱管理逻辑拆分到CargoCompartment类，避免了Flight类和Main类的职责冗余，使代码结构更加清晰，后续修改和扩展也更加方便。例如，当需要修改输入校验规则时，只需修改InputValidator类，无需改动其他类，降低了代码的耦合度。

（三）作业3：旅客管理与载重平衡计算模块

1. 核心需求与业务落地

作业3是系列作业的最终迭代，完全模拟真实航空配载业务，核心需求包括：新增旅客（Passenger）与行李（Luggage）类，二者为组合关系（旅客必须携带行李）；实现载重平衡计算（总重量、总力矩、重心、重心百分比）；判断飞行安全状态，输出标准化载重平衡舱单；严格遵循单一职责原则，禁止使用继承、接口，排序需用循环实现。

核心难点：组合关系实现、复杂载重平衡公式精准实现、纯工具类设计、标准化舱单格式输出。

2. 类设计与类图

在作业2基础上新增两个核心类，完善类结构，严格遵循单一职责原则：

Luggage类：仅记录行李重量，提供getter方法，职责单一，作为Passenger类的组成部分。

Passenger类：管理旅客信息，包含Luggage对象（组合关系），计算旅客总重量（标准体重75kg+行李重量）。

WeightBalanceCalculator类：纯计算工具类，包含静态常量（空机重量、力臂等），提供载重平衡计算和舱单输出方法，与Flight类为依赖关系。

原有类扩展：Flight类新增旅客列表，提供添加旅客、计算旅客总重量方法，其他类职责不变。

PowerDesigner类图

3.SourceMonitor 代码度量分析

使用SourceMonitor工具对作业2的代码进行度量，具体结果如下表所示：

从度量结果看：代码的复杂度控制、方法长度、嵌套深度等指标表现优秀，整体结构清晰、易维护。
唯一短板是注释率为 0%，补充关键注释后，代码的可维护性会大幅提升。

5. 设计心得与反思

本次作业让我理解组合关系的使用场景，旅客与行李不可分割，行李在旅客内部创建。纯工具类的设计，让我体会到依赖关系的优势，计算逻辑与业务数据分离，降低耦合度。

三、采坑心得与经验总结

结合三次作业的测试反馈、代码调试结果，现将核心踩坑点、对应错误及解决办法精简总结

1.排序算法不符合要求，边界处理疏漏，影响业务逻辑准确性：作业1要求用循环实现排序，用冒泡排序后，因忽视边界场景（如货物重量相同、仅装载一件货物），导致排序结果异常，补充边界逻辑后解决。
解决前：

解决后：

2. 货舱超载提示问题：初期仅判断超载，未按题目要求输出警告提示，补充输出逻辑后通过测试；货舱校验需实时进行，每添加一件货物就检查。

3. 重心公式实现问题：作业3因公式顺序颠倒导致结果错误，对照题目公式逐行核对后解决。
   解决前：
   
   解决后：
   

四、改进建议

结合三次作业的问题，提出以下改进方向，实现可持续优化：

1. 代码结构优化：提炼通用方法，减少重复代码（如多个货舱装载逻辑）；拆分工具类，将校验、排序、计算功能分开，避免工具类臃肿。

2. 边界优化：针对作业1-3中边界场景遗漏的问题，新增边界校验补充代码——作业1补充最大载重为0、货物件数为0的处理逻辑，作业2补充货舱行数列数为0、货物编号非数字的处理逻辑，作业3补充旅客行李重量为0、旅客编号校验的逻辑。

3. 注释优化：进一步完善关键公式、复杂逻辑、边界处理的注释，提升代码可维护性，便于后续自查和修改。

五、总结

这三次作业让我摆脱了面向过程的固化思维，建立起模块化、解耦的编程思维，熟练运用封装、组合、依赖关系。同时也明确了自身不足：边界处理意识薄弱、代码优化和异常处理能力欠缺。后续我将针对性改进这些不足，夯实编程基础，提升代码质量和系统设计能力，为后续编程学习和专业实践筑牢基础。

建议：PTA题目集和实验以及报告时间重复，建议可以错开时间