面向对象设计与构造 —— 三次迭代作业总结
一、前言
本阶段的三次 Java 迭代作业已经全部完成，回顾整个开发与学习过程，三次作业围绕航空器配载与货运管理系统迭代开发展开增量式的功能扩展，完成了从基础单货舱配载，到多货舱管理，最终到完整的载重平衡与重心计算的逐步迭代。
从知识点覆盖来看，三次作业依次覆盖了不同阶段的Java开发与面向对象设计能力：
1. 第一次作业：Java基础类设计、单一职责SRP原则、基础输入输出处理、简单重量校验逻辑
2. 第二次作业：多货舱管理、类的组合与聚合关系、货物排序调度、输入校验工具类设计
3. 第三次作业：旅客与行李管理、航空器载重平衡计算、重心MAC百分比换算、自定义冒泡排序、输入合法性校验
题量方面，三次作业采用单题迭代的开发模式，每次作业在原有功能基础上新增需求点，整体功能点逐步扩展：
第一次作业核心功能点约5个，第二次作业新增7个功能点，第三次作业新增8个功能点，整体符合迭代开发的节奏。
难度方面，三次作业的能力要求逐步提升：
1. 第一次作业以熟悉Java开发流程、掌握基础类设计为主，整体难度较低；
2. 第二次作业始要求类的关系设计，需要理解组合与聚合的区别，难度中等；
3. 第三次作业需要处理业务计算与自定义排序，对逻辑的严谨性要求较高，整体循序渐进，帮助我逐步完成了从基础到进阶的能力过渡。
二、设计与分析
1.第一次作业
（1）作业需求
实现基础单货舱航班货物配载功能，需读取航班基础信息、最大载重限值，批量录入货物数据，按照货物重量降序完成自动装载，统计航班总装载重量，自动判别配载超载状态，最终输出完整货物清单与配载结果。
（2）整体代码架构与类设计
结合本人本次迭代源码，共设计五个核心结构，各模块职责边界清晰，严格贴合SRP单一职责原则:
|
类名称 |
职责描述 |
|
Cargo货物实体类 |
仅用于存储货物名称、重量核心数据，仅提供getter方法，无任何业务逻辑，是纯粹的数据实体类。 |
|
Flight航班类 |
负责维护航班号、最大载重等航班基础属性，绑定配载清单对象，专注航班基础信息管理，不参与货物装载逻辑。 |
|
LoadManifest配载清单类 |
核心业务处理类，承担货物装载、总重量统计、超载状态判断、结果信息打印等核心业务功能。 |
|
CargoSorter排序工具类 |
封装静态选择排序方法，仅负责实现货物重量降序排序，职责纯粹、复用性强。 |
|
Main主类 |
仅承担程序入口、数据输入读取、整体流程串联的功能，完全剥离业务逻辑。 |
整体类依赖关系简洁清晰，Main入口类调用工具类与业务类，Flight与LoadManifest形成双向关联，Cargo作为基础实体被上层业务调用，整体实现高内聚、低耦合的基础设计目标。
（3）类图分析
关联关系：Flight航班类与LoadManifest配载清单类为双向关联，航班绑定配载清单，清单归属对应航班；
依赖关系：排序工具类依赖Cargo货物类完成重量排序，Main主类依赖所有业务类串联流程；
核心特征：无组合/聚合关系，结构简单，所有货物统一装载至单一份配载清单，完全匹配V1单货舱业务逻辑
（4）SourceMonitor复杂度分析
1. Cargo 货物实体类
指标表现：所有方法v(G)=1、ev(G)=1、iv(G)=1，WMC极低，OCavg=1.0
分析：该类为纯粹的数据实体类，仅包含私有属性、构造方法、getter取值方法，无任何业务逻辑、无判断循环分支。代码完全扁平化、无嵌套、无外部依赖，严格遵循单一职责原则，是标准的高质量实体类设计。
2.Flight 航班类
指标表现：复杂度全部趋近于1，无高分支逻辑
分析：该类仅负责存储航班编号、最大载重等基础属性，提供基础的set、get方法，仅简单关联配载清单类，无计算、无判断、无业务流程。代码结构干净、耦合度极低，完全符合实体属性类的设计规范，无任何代码质量问题。
3.CargoSorter 排序工具类
指标表现：核心排序方法 v(G)=5、ev(G)=4、iv(G)=2，为全项目最高复杂度节点
问题成因：采用选择排序算法，存在双层for循环嵌套，同时包含大小判断、位置交换逻辑，产生多条执行路径，直接拉高圈复杂度。且方法直接依赖Cargo实体类与List集合，存在轻微外部依赖，导致设计复杂度偏高。
优劣分析：该复杂度属于算法固有合理复杂度，无冗余代码、无无效分支，逻辑简洁无BUG，但双层嵌套导致结构化程度偏低，是V1版本最主要的复杂度来源。4. LoadManifest 配载清单业务类
4. LoadManifest 配载清单业务类
指标表现：打印与超载判断方法v(G)=4，其余方法复杂度为1
分析：高复杂度集中在 printManifestInfo 输出方法与超载判断方法。原因是输出方法包含多场景文本打印、超载/正常双分支判断、重量拼接逻辑，分支较多。同时业务方法直接承担数据统计、状态判断、结果输出多重职责，存在轻度职责耦合。
优点
1、实体类设计规范：Cargo、Flight类职责纯粹、复杂度极低，完全符合面向对象单一职责设计思想。
2、业务逻辑清晰：装载、排序、判断、输出流程线性执行，无冗余逻辑、无无效嵌套，代码可读性高。
3、算法逻辑干净：选择排序无多余判断，分支精简，无BUG风险，属于合理复杂度。
缺陷与不足
1、主类严重耦合：所有业务流程堆砌在Main方法，无分层、无封装，无法复用、无法扩展。
2、业务类职责混杂：LoadManifest同时承担计算、判断、输出功能，不符合单一职责。
3、无统一数据校验：未封装输入校验逻辑，存在非法数据输入风险，程序健壮性差。
4、架构无扩展性：仅适配单货舱场景，未预留多货舱、多参数扩展接口，架构前瞻性不好
（5）时序图分析
优点
1. 流程逻辑直观清晰：整体采用线性串行执行方式，从上至下依次执行输入、排序、装载、校验、输出，无跳转逻辑、无复杂依赖，可读性极强，符合入门面向对象编程的设计思路。
2. 职责调用关系明确：Main统一调度、工具类专注排序、业务类专注装载判断、实体类仅存数据，初步实现了不同类的职责分离，符合单一职责原则的基础设计思想。
3. 贴合基础业务场景：完美模拟了简单航班单舱货物配载的真实流程，能够完整支撑V1版本的所有功能需求。
缺陷（迭代伏笔）
1. 流程高度集中耦合：所有调度、输入、流程控制逻辑全部集中在Main主类中，没有分层封装，主类负担过重，与时序复杂度偏高、代码臃肿的问题完全对应。
2. 架构无扩展性：时序流程仅支持单航班、单货舱、单次配载，无法适配多货舱、分区装载、多级重量校验的复杂场景，架构前瞻性不足。
3. 容错机制缺失：时序流程中无数据校验环节，未对负数、零、非法数值做拦截，一旦输入异常数据会直接导致程序报错，程序健壮性弱。
4. 业务与输出未分离：业务判断逻辑和结果打印逻辑集中在同一个业务类中，流程耦合度高，不利于后期维护与迭代升级。
时序设计心得
采用线性串行执行流程，流程简单直观、逻辑清晰，能够快速落地基础业务功能，适合入门级面向对象开发练习。但整体执行流程全部堆砌在Main主方法中，缺乏分层设计与模块解耦，仅能适配简单单舱场景，无法支撑多货舱、多维度校验的复杂业务扩展，架构前瞻性不足，也为第二次迭代重构埋下了优化伏笔。
(6)设计心得
第一次迭代让我真正落地了面向对象单一职责原则，清晰区分了实体类、工具类、业务类、入口类的职责边界，摆脱了纯面向过程的编程思维。同时，自主实现选择排序算法，有效锻炼了基础算法编写与逻辑调试能力。 但本次设计的短板也十分突出：核心业务输出逻辑高度耦合、主方法流程堆砌严重、未预留扩展接口，架构设计仅满足当下功能，缺乏迭代思维。这让我深刻认识到，项目开发不仅要实现功能，更要兼顾代码结构与可扩展性，为后续迭代迭代提供支撑。
2.第二次作业
(1) 作业需求回顾
第二次迭代在第一次基础上完成全面架构重构与功能升级，支持多货舱独立管理。每个货舱拥有独立最大载重限值与行列网格位置，货物绑定指定目标货舱，按重量降序稳定排序装载。程序需分层校验单货舱超载状态、航班整体最大起飞重量超载状态、最大业载超载状态，输出精细化的分层配载结果与异常提示。
（2）整体代码架构与类设计
|
类名称 |
职责描述 |
|
Position位置类 |
存储货舱行列坐标，生成唯一位置名称，与货舱为组合关系，货舱实例化即自动生成完整位置网格，生命周期与货舱绑定。 |
|
CargoCompartment货舱类 |
独立管理单货舱的载重限值、位置集合、货物集合，实现单舱货物装载与实时重量统计，独立判断单舱超载状态。 |
|
LoadDispatcher调度类 |
重构排序算法为冒泡排序，实现货物稳定排序，新增货物查找功能，作为纯工具类服务全局业务。 |
|
InputValidator校验工具类 |
封装整数、浮点数、范围校验通用方法，统一全局数据合法性判断，减少代码冗余。 |
|
Flight航班类 |
升级为多货舱容器，统一管理所有货舱对象，统计航班整体载重数据，维护航班核心参数。 |
|
FlightCargoSystem系统主类 |
封装全部业务流程，替代原始轻量化Main类，实现业务逻辑与程序入口彻底分离。 |
本次迭代精准区分组合关系（货舱与位置）、聚合关系（货舱与货物），位置依附货舱存在，货物可独立装卸、灵活调配，完全符合面向对象关联设计规范。
（3）类图分析
组合关系：货舱与位置为强组合，货舱销毁则位置网格同步销毁；航班与货舱为强组合，航班包含全部货舱；
聚合关系：货舱与货物为弱聚合，货物可独立存在、自由调配至不同货舱；
架构升级：废弃单一配载清单，以货舱为核心业务单元，新增数据校验、货物调度模块，彻底解耦业务与入口逻辑。
（4）SourceMonitor复杂度分析
1. Position 位置实体类
指标表现：全部方法 v(G)=1，ev(G)=1，iv(G)=1，WMC极低
分析：该类为纯数据实体，仅存储行列坐标、位置名称，构造方法与Getter方法扁平化执行，无循环、无判断、无业务逻辑。与货舱为组合关系，但自身不依赖任何外部业务，完全符合单一职责，代码质量极高。
2. CargoCompartment 货舱核心业务类
指标表现：多数方法复杂度为1，仅装载、超载判断方法 v(G)=2~3，处于极低水平
分析：作为第二次迭代新增核心业务类，承担单货舱重量统计、货物装载、单舱超载判断。虽然具备业务能力，但逻辑拆分精细：装载只负责装载、统计只负责统计、判断只负责判断，没有方法堆砌。 相比V1的LoadManifest大包类，本次职责粒度更细、分支更少、可读性更强，是本次重构最大的亮点。
3. Cargo 货物类
指标表现：全维度复杂度=1
分析：延续第一次迭代的优秀设计，仅扩展目标货舱ID属性，依旧保持纯粹实体特征，无任何业务侵入，结构干净稳定。
4. Flight 航班容器类
指标表现：整体OCavg偏低，仅汇总重量、全局超载判断存在少量分支
分析：Flight不再直接处理货物，转变为多货舱容器管理类，只负责管理子货舱集合、汇总整机重量、判断整机超载。完全剥离细节业务，符合“高层统筹、底层细化”的分层思想，耦合度大幅降低。
5. LoadDispatcher 货物调度工具类（全局最高复杂度）
指标表现：自研冒泡排序方法 v(G)=6，为全项目最高值
原因分析：为满足作业稳定排序要求，自研双层循环冒泡排序，包含相邻比较、位置交换、循环遍历逻辑，路径较多，拉高圈复杂度。
合理判定：该复杂度属于算法固有逻辑，无冗余判断、无无效嵌套，相比第一次迭代的选择排序，结构更规整、稳定性更高，ev(G)基本复杂度更低，结构化优于V1。
6. InputValidator 全局校验工具类
指标表现：方法分支少、复用性高、设计复杂度极低
分析：第二次迭代新增通用校验层，将所有数值判断、正负校验、范围校验统一抽离，彻底解决V1“校验散落、重复代码多”的问题。工具类完全解耦业务，只提供通用能力，设计非常规范。
7. FlightCargoSystem 系统主调度类
指标表现：流程长但分支少、嵌套浅，OCavg优秀
分析：彻底干掉第一次迭代的臃肿Main主类，将所有流程封装至System业务调度类。虽然整体流程较长，但采用分步调用、分层执行，无复杂嵌套，逻辑清晰，完全实现业务与入口解耦。
优化点
1. 彻底解决主类耦合问题：废弃Main大包写法，新增系统调度类，流程结构化，不再出现代码堆砌。
2. 业务职责彻底拆分：V1一个清单类包揽所有业务，V2拆分为货舱装载、全局调度、数据校验、排序算法四大模块，单一职责落地到位。
3. 重复代码大幅减少：全局统一校验工具类，消除大量重复if判断，代码更加优雅。
4. 设计复杂度显著下降：类与类之间依赖变弱，仅通过方法传参交互，不再强耦合，扩展性大幅提升。
5. 算法结构优化：将不稳定选择排序重构为稳定冒泡排序，在复杂度可控前提下，提升业务准确性。
遗留缺陷
1. Position位置模块利用率不足：位置网格仅完成初始化存储，未参与货物分配与定位校验，属于冗余数据，代码功能利用率低。
2. 异常终止机制简单：遇到超载或非法数据直接终止流程，无优雅异常提示，程序健壮性仍有提升空间。
3. 输出逻辑仍有散落：打印提示分散在业务类中，未完全统一管理，存在轻微冗余。
4. 未涉及民航真实配平逻辑：仅实现重量超载判断，无重心、力矩、配平安全校验，业务深度不足。
（5）时序图分析
优化点(相比第一次迭代)
1. 彻底解耦，流程工程化: 抛弃V1所有逻辑集中在Main类的模式，采用专门的系统调度类统筹全局，校验、排序、装载、判定、输出各司其职，模块完全解耦，时序层级清晰，无逻辑堆砌。
2. 新增前置数据校验机制: V1无时序校验环节，非法数据易导致程序崩溃；V2将校验前置，所有参数先校验后使用，大幅提升程序健壮性。
3. 实现多舱分区业务时序: 从V1单一线性装载，升级为多容器、分区独立装载、分层校验的复杂时序流程，高度贴合真实民航货运配载场景。
4. 排序算法时序更严谨: 使用稳定冒泡排序替代选择排序，时序执行中保证同重货物顺序不变，业务逻辑更严谨，符合作业规范。
遗留缺陷
1. 位置模块时序闲置：Position位置网格仅在初始化阶段创建，在后续货物装载、校验流程中未参与调度，时序链路存在冗余模块，功能利用率低。
2. 无航空配平时序：时序仅实现重量超载判断，缺少力矩计算、重心配平、安全区间判定等核心民航逻辑，业务深度不足。
3. 异常流程处理简单：时序中遇到超载、数据异常直接终止程序，无重试机制、无优雅异常回调，容错流程单一。
4. 未支持旅客行李业务：时序链路仅覆盖货物配载，缺少旅客、行李重量统计流程，无法模拟完整航空器载重场景。
时序设计心得
第二次迭代版本彻底解决了初代代码流程耦合、职责混乱的问题，实现了校验、排序、装载、判定、输出的分层解耦执行，时序流程高度贴合真实民航地勤配载的作业逻辑，业务严谨性
大幅提升。同时本次迭代存在明显瑕疵：Position位置网格完成初始化后，未参与后续货物分配与业务校验，仅作为冗余数据存在，功能利用率低，是本次架构设计的主要短板，也为第三
次迭代优化提供了方向。
（6）设计心得
第二次迭代是我面向对象设计思维成型的关键阶段。通过本次开发，我彻底厘清了组合与聚合的核心区别，理解了类与类之间关联关系的设计逻辑，不再局限于单一类的功能实现，而是从整体架构角度设计系统。 同时，通用工具类的抽离让我体会到代码复用的重要性，将校验、排序、查询等通用逻辑与核心业务剥离，让业务代码更纯粹、逻辑更清晰，有效规避了代码冗余、重复开发的问题，为第三次迭代的系统化开发奠定了基础。
3.第三次作业
（1）作业需求
|
类名称 |
职责描述 |
|
Luggage行李类 |
轻量化实体类，仅存储行李重量数据，无多余业务逻辑。 |
|
Passenger旅客类 |
与行李为组合关系，在构造器内部自动创建行李对象，封装单人总重量计算逻辑（75kg标准人体重量+行李重量），精准贴合民航重量统计标准。 |
|
WeightBalanceCalculator配平计算类 |
纯静态工具类，无成员变量，仅接收Flight航班对象作为参数，独立完成航空力矩、总重量、重心、MAC百分比等核心计算，完全与业务层解耦。 |
|
InputValidator优化升级 |
新增负数强制拦截、数值范围校验，所有输入数据前置校验，非法数据直接终止程序并提示，大幅提升系统健壮性。 |
本次架构最大优势为算法与业务完全分离，航空配平计算逻辑独立封装，后续修改计算公式、调整机型参数、更新安全标准，仅需修改工具类，无需改动整体业务流程，扩展性极强。
（3）类图分析
1、新增核心组合：旅客与行李为强组合，旅客实例化自动绑定行李，贴合民航人员重量统计规范；
2、解耦核心：载重配平计算类为纯静态工具类，与业务层完全解耦，仅依赖航班数据完成力学计算，扩展性极强；
3、参数升级：货舱新增力臂属性，航班新增空机重量、空机力臂核心参数，满足航空重心、力矩计算需求；
4、校验强化：工具类专注非负数据拦截，前置校验所有输入，大幅提升程序健壮性。
（4）SourceMonitor复杂度分析
1. Luggage 行李实体类
指标表现：所有方法 v(G)=1、ev(G)=1、iv(G)=1，无任何复杂逻辑
分析：作为V3新增实体类，仅用于存储行李重量属性，提供基础getter方法，完全为数据载体。无业务逻辑、无判断循环，结构极简，严格遵循单一职责原则，代码质量优秀。
2. Passenger 旅客类
指标表现：整体复杂度极低，仅存在简单组合调用逻辑
分析：旅客类与行李类形成强组合关系，内部封装民航标准人体重量与行李重量汇总逻辑。计算逻辑公式固定、分支极少，方法扁平化执行，没有冗余嵌套。同时静态常量定义规范，代码可读性极高。
3. Position 位置类、Cargo 货物类
指标表现：全维度复杂度趋近于1，无任何质量问题
分析：延续前两次迭代的优秀设计，全程保持纯粹实体属性，不参与任何业务计算与流程调度，代码稳定、零耦合，是项目中最稳健的基础模块。
4. CargoCompartment 货舱类
指标表现：装载、超载预判方法 v(G)=2~3，整体OCavg极低
分析：V3为货舱新增力臂属性用于力矩计算，但未破坏原有结构。所有方法依旧保持单一职责：装载只负责装载、预判只负责预判、取值只负责取值。相比V1臃肿业务类，V3货舱类逻辑粒度极细，结构化程度高，无代码堆积。
5. Flight 航班类
指标表现：流程统筹逻辑简单，无高分支复杂度
分析：航班类升级为整机数据容器，统一管理货舱集合与旅客集合，仅负责数据汇总与存储，不再处理具体业务细节。完全符合高层抽象、底层实现的工程思想，耦合度极低。
6. WeightBalanceCalculator 载重配平计算类（核心亮点）
指标表现：平均复杂度仅1.5，几乎无分支、无嵌套
分析：该类为纯静态工具类，独立承担所有航空力矩、重心、MAC百分比计算。所有方法均为公式计算逻辑，if判断极少、无循环嵌套、结构极度干净。
最大优势为完全解耦业务：计算层与业务层彻底分离，参数修改、公式更新、安全区间调整均可独立完成，不影响主流程，是三次迭代中高内聚低耦合的最佳实践。
7. InputValidator 数据校验工具类
指标表现：方法精简、分支单一、复用性极强
分析：进一步强化全局校验，统一拦截负数、非法数值、越界数据。所有校验逻辑前置、通用逻辑抽离彻底，消除了项目中所有重复if判断，让业务代码更加纯粹，大幅提升系统健壮性。
8. FlightCargoSystem 系统调度类
指标表现：流程长但复杂度低，无嵌套、无复杂分支
分析：虽然V3业务最复杂（多旅客、多货物、多舱装载、配平计算、安全判定），但调度类全程采用分步调用、线性执行，没有把所有逻辑写在一个方法内，而是分层调用各模块能力，实现了“业务复杂但代码不乱”的优质效果。
9. 自研冒泡排序算法模块（全局最高复杂度）
指标表现：v(G)=7，为全项目最高复杂度
分析：该复杂度为算法固有合理复杂度，双层循环+相邻交换逻辑不可避免，但代码结构规整、无冗余判断、无无效嵌套，ev(G)基本复杂度很低，结构化程度优秀。相比V1选择排序，稳定性、可读性、规范性全面升级。
（5）时序图分析
核心亮点
1. 新增完整旅客行李时序链路： 相比前两版仅支持货物配载，V3新增旅客、行李组合载重流程，完整模拟真实航班的全部载重来源，业务场景更加贴合民航实际。
2. 实现装载前置预判机制： 优化V2装载后才判断超载的滞后逻辑，改为先预判、后装载，业务逻辑更严谨，完全匹配真实地勤配载作业规范。
3. 计算层彻底解耦，时序分工极致： 将复杂的航空重心、力矩计算完全抽离为独立模块，时序上不侵入装载流程，实现业务流程与科学计算的彻底分离，架构优雅、扩展性极强。
4. 全局强校验全覆盖： 时序流程起始即加入数据强校验，规避非法数据导致的计算异常，解决V1无校验、V2校验不完善的历史问题，程序稳定性大幅提升。
遗留缺陷
1. 位置网格模块时序闲置：Position位置对象仅在初始化阶段创建，未参与货物精准定位与分配时序，模块利用率不足，存在轻微功能冗余。
2. 异常终止逻辑较粗暴：遇到超载、参数非法等异常，直接终止程序，无自定义异常提示、无流程恢复机制，用户交互体验有待优化。
3. 输出模块未独立解耦：舱单打印、提示输出逻辑散落于调度时序中，未封装独立输出工具类，时序职责可进一步细化。
时序设计心得
第三次迭代的时序架构达到三次开发中的最优状态，完美实现高内聚、低耦合、强健壮性的设计目标。所有新增功能均通过新增类完成，完全遵循开闭原则；前置校验、实时拦截、分层计算的流程设计，让程序容错性与规范性大幅提升。本次设计的微小不足为：程序异常处理较为简单，采用System.exit(0)强制终止程序，无优雅的异常提示与流程恢复机制，后续可进一步优化。
（6）设计心得
第三次迭代让我真正理解了工业级业务系统的设计逻辑。首先，实体类精细化拆分，旅客与行李的组合设计贴合现实物理关系，让代码更贴合真实业务；其次，核心计算算法完全与业务解耦，参数统一常量配置，便于后期维护与迭代；最后，前置校验、实时容错的设计思维，从源头规避了非法数据与业务bug，大幅提升了程序稳定性。
整套开发流程让我彻底摆脱了“功能优先、忽略结构”的开发误区，建立了结构优先、兼顾功能、预留扩展的工程化开发思维。
三、踩坑心得
结合本人三次迭代完整源码开发、本地调试、平台提交的真实经历，总结可复现、可落地的核心问题，真实还原迭代过程中的调试与改错过程：
坑点1：V1版本Scanner换行符残留，导致货物名称读取为空
问题现象
初代开发时，使用nextInt()读取数值后，缓冲区残留回车换行符，未及时吸收，导致后续nextLine()读取货物名称时获取空字符串，出现数据读取错位、部分测试点运行异常的问题。
问题分析
属于Java Scanner输入流经典问题，数值读取方法不吸收换行符，残留符号会被后续行读取方法捕获，导致数据读取异常。
解决方案
在数值读取操作后，手动添加sc.nextLine()吸收残留换行符，清空缓冲区，彻底解决数据读取错位问题，所有测试点正常通过。
坑点2：V2冒泡排序判断逻辑错误，同等重量货物排序紊乱
问题现象
初始冒泡排序使用<=作为判断条件，导致同等重量货物发生位置交换，破坏了作业要求的同重保序规则，测试点输出顺序错误。
问题分析
排序判断条件设计失误，实现了不稳定排序，违背了“重量降序、输入顺序优先”的业务规则。
解决方案
修改判断逻辑，仅当当前货物重量小于后序货物时交换位置，重量相等时不做操作，保证同等重量货物保留原始输入顺序，实现稳定排序。
坑点3：V3前后货舱力臂参数绑定颠倒，重心计算全部失效
问题现象
初次开发时混淆前后舱力臂参数，将前舱12.0m、后舱22.0m力臂写反，导致所有力矩计算数据错误，重心百分比始终超出安全区间，配平结果全部判定为危险。
问题分析
航空配平公式参数严谨性极高，力臂与货舱绑定关系错误，会直接导致整套力学计算失效，属于业务逻辑细节失误。
解决方案
严格匹配货舱ID与力臂参数，ID为1的前舱对应12.0m力臂，ID为2的后舱对应22.0m力臂，修正参数后，所有计算数据与标准样例完全一致。
坑点4：V3货舱超载判断时机滞后，无法触发标准提示
问题现象
初始代码在货物装载完成后才判断超载，无法实现装载前预判，无法输出作业要求的“剩余容量不足”警告，不符合作业输出规范。
问题分析
业务逻辑顺序设计不合理，未遵循“先预判、后执行”的配载原则。
解决方案
调整逻辑执行顺序，装载前计算「当前载重+待装货物重量」，提前预判超载，触发标准化警告并终止程序，完全匹配作业规范。
四、改进建议
基于三次迭代完整源码、复杂度分析、时序流程复盘，结合代码短板与业务缺陷，提出可落地、可优化的迭代改进方案：
1. 代码架构优化
三次迭代的输出打印逻辑均散落在各业务类中，可统一封装全局打印工具类，实现输出逻辑与业务逻辑彻底解耦；航空配平的静态常量分散在计算类中，可单独创建常量配置类，统一管理机型参数、力臂数值、安全区间等数据，便于后期修改与维护。
2. 排序算法优化
本次自研冒泡排序时间复杂度偏高，后续可在不使用官方工具类的前提下，优化为高效稳定的插入排序，提升大批量货物排序效率；同时新增排序策略扩展，支持按货物ID、重量、录入时间多维度排序，适配更多业务场景。
3. 业务功能完善
目前Position位置类仅完成初始化，未参与货物分配业务，后续可开发货物精准位置分配功能，实现货舱网格位置的精细化管理，完善系统业务闭环；新增货物卸载、批量替换、配载重置功能，丰富系统操作场景。
4. 程序健壮性提升
摒弃粗暴的System.exit(0)程序终止方式，自定义业务异常类，实现优雅的异常提示与流程终止；新增空对象、空集合判空处理，彻底杜绝空指针异常，提升程序稳定性与用户体验。
五、总结
学习收获
经过三次迭代开发，我系统完成了从基础语法编程到面向对象工程化开发的能力跃迁，核心收获如下：
1. 熟练掌握Java类的设计、组合与聚合关系，深刻理解单一职责、开闭原则在实际项目中的落地方式，能够独立完成模块化、低耦合的系统架构设计。
2. 掌握自定义算法实现、输入流处理、全局数据校验、UML类图与时序图绘制、代码质量量化分析的完整开发流程。
3. 熟练掌握迭代开发与代码重构思维，能够在原有稳定代码基础上扩展新功能，最大限度减少代码改动、保证系统稳定性。
4. 结合真实民航配载业务，理解了载重、力矩、重心配平的专业知识，实现了代码开发与行业业务的深度结合。
5.在下次进行项目开发时，应该提前构建好代码的结构，不要等到写代码的中途再去修改结构，到时逻辑混乱
自我不足
迭代过程中也暴露了自身的短板：前期架构设计前瞻性不足，初代代码存在耦合冗余问题；对业务细节、公式参数的严谨把控不足，容易出现细节失误；异常处理、代码优化能力仍需提升，开发重心偏向功能实现，对代码质量的打磨不够细致。
课程与作业建议
建议增加代码质量互评环节，围绕代码复杂度、职责拆分、架构设计开展互评，提升学生的工程化代码设计能力。
浙公网安备 33010602011771号