面向对象设计与构造——航班货运配载系统三次迭代作业总结

面向对象设计与构造 —— 航班货运配载系统三次迭代作业总结

这段时间我完成了航班货运配载系统的三次迭代作业，从最基础的单货舱装货，一步步做到多货舱分区、超载检查，最后还加入了旅客行李管理、飞机力矩计算和重心配平，做出了一套贴近真实航空地勤工作的小型配载系统。整个过程用 Java 开发，没乱用复杂的继承、多态，就是老老实实拆分类、理清职责，慢慢把程序从简单慢慢的完善，让它从最初一点点小功能，到现在功能种类变多。下面我就把这三次迭代的过程、设计思路、踩过的坑和收获，做成汇报。

一、三次迭代：从简单到完整的需求变化

1. 第一次作业：单货舱基础装载

 

第一次作业是整个项目的起点，功能很简单，只做单货舱货物配载。输入航班的最大载重，批量录入货物，按重量从大到小排好顺序依次装上飞机，最后算总重量、判断有没有超载。

这次我只建了航班、货物两个核心实体类，加上主程序入口，把数据和简单逻辑分开，实现了输入、排序、输出、超载判断这些基础功能，算是搭好了整个项目的架子。

2. 第二次作业：多货舱分区 + 双重超载校验

 

第二次在第一次的基础上做了大升级，不再是单一货舱，而是改成多货舱分区装载。我加了货舱类、位置网格类，还把航班的载重限制分成最大起飞重量和最大业载重量，既要检查单个货舱有没有超载，也要判断整个航班是否超重。

同时我专门拆出了调度类和输入校验类，让每个类只干一件事：调度类负责排序，校验类负责检查数据合法性，航班类统一管理多个货舱，整体更贴近真实的分区装货流程。

3. 第三次作业：旅客行李 + 重心配平

 

第三次是难度最高、也最贴近真实飞行安全的版本。在多货舱装载的基础上，加入了旅客和行李，按照航空标准计算每个人的重量，还实现了飞机重心配平计算。

系统能算出空机重量、各部分力矩、总重量、总重心，再换算成 MAC 重心百分比，判断飞机是否在安全飞行区间，最后输出标准的载重平衡舱单。这一步直接让程序从 “算重量的小工具”，变成了能做飞行安全评估的配载系统。

二、各版本设计与核心实现思路

1. 第一次作业：简单清晰的基础结构

第一次的类很少，分工很明确：

Flight 类：只存航班号、最大载重，管航班基础数据；

Cargo 类：只存货物名称和重量，纯数据模型；

Main 类：负责输入输出、排序、装载、判断超载，统筹整个流程。

逻辑也很直接：读数据→存货物→手动冒泡排序→按重量从大到小装货→算总重→判超载，数值统一保留一位小数，保证输出格式规范。

当然这个版本缺点也很明显：只有一个货舱，没有旅客和重心计算，输入校验很简单，逻辑都挤在主类里，不太好扩展。

这第一次作业代码总量最小相对来讲编写起来最为简单，所用时间也是最少的。

2. 第二次作业：类结构细化，关系更清晰

第二次我加了好几个类，把功能拆得更细：

Position 类：管货舱的行列位置，和货舱绑定在一起；

CargoCompartment 类：单独管一个货舱的载重、货物列表；

LoadDispatcher 类：专门做货物排序，把逻辑从主类挪出来；

InputValidator 类：统一检查输入是否合法。

航班类也升级了，能管理多个货舱，支持按 ID 找货舱。核心功能就是货物绑定目标货舱，定向装载，分别校验单舱和整机超载，分出正常、超起飞重量、超业载重量、双重超载四种状态。

这里我特别注意了组合和聚合的区别：货舱和位置、旅客和行李是强绑定的组合关系，货舱和货物是可分离的聚合关系，符合真实的对象关系逻辑。

3. 第三次作业：完整工业级小系统

第三次是最终完善版，类的数量到了 10 个左右，全程没用继承、多态、接口，完全按要求来：

Luggage 类：只存行李重量；

Passenger 类：自带行李，按 75kg 标准体重 + 行李重量算总重；

WeightBalanceCalculator：核心工具类，封装所有配平计算公式；

InputValidator：全面优化，遇到负数、超范围数据直接终止程序；

LoadDispatcher：纯手写冒泡排序，不用系统自带方法。

配平计算完全按照航空规范来：先定好空机参数、各舱力臂，再分别算旅客、货舱的重量和力矩，累加得到总数据，算出重心和 MAC 百分比，对照 25.0%~38.0% 的安全区间，给出安全或危险的判断。同时把各种边界情况都处理好，比如提前校验货舱容量，避免溢出装载。

三、核心设计原则：简单、清晰、不混乱

整个三次迭代，我一直坚持一个原则：一个类只干一件事。实体类只存数据，工具类只算逻辑，调度类只排流程，校验类只查输入，主类只做总调度。这样代码不臃肿，改起来也方便。

另外我严格区分组合和聚合关系，该绑定的绑定，该分离的分离，对象关系很清晰。排序也全程手写冒泡排序，不依赖系统工具，保证算法规范。

四、迭代踩坑实录：那些坑过我的问题

1. 第一次：排序错、输入乱

第一次最坑的不是代码报错，是排序规则没吃透。我一开始写的排序和题目要求的重量降序不一致，同重量货物顺序也乱了，导致装载顺序、总重量、超载判断全错。

还有 Scanner 输入的坑，nextInt、nextDouble 会留换行符，导致 nextLine 读到空字符串，输入直接错乱。后来我重写了冒泡排序，严格按要求来，再用空 nextLine 吸收换行，才解决问题。

2. 第二次：格式不对、货舱乱装

第二次功能都做对了，却一直过不了测评，最后发现是输出格式差一点都不行—— 空格、小数位数、语句顺序、措辞，测评系统都卡得很严。

还有货舱 ID 没处理好，所有货物都塞到同一个舱里，分区装载失效。后来加了按 ID 匹配货舱的方法，拆分四种超载状态，再一点点改输出格式，才终于通过。

3. 第三次：公式错、规则特殊

第三次是坑最多的一次：

前舱行李序号，测评要求从 1 开始，我按编程习惯从 0 开始，一直报错；

超载时要输出限定重量，我输出了实际超重重量，数据全错；

重心公式混淆了参数，还漏了旅客 75kg 标准体重，配平结果完全不对。

后来对着测试点一点点改规则、调公式、补全逻辑，才把所有问题都修好。

4. 通用问题：逻辑挤在主类

一开始我习惯把所有代码写在 Main 里，又长又乱，改起来费劲。后来慢慢学会拆分逻辑，把排序、校验、计算都抽成独立类，代码清爽多了。

每一次的作业都会因为一些测试点导致我长时间卡在一个地方，总改也改不对，不清楚测试点的具体要求，以及自己代码与测试点要求的差距。尤其是在第二个作业中时，不根本不清楚十个测试点都是什么，我只能看到case1-case10，提交以后发现有测试点过不去，我再改代码的时候也不清楚从何处下手，后来在其他同学的帮助下，我才发现测试点的要求是输出格式的不对。

五、代码复杂度与可优化点

整体来看，因为类拆得细，单个方法都不复杂。冒泡排序，但货物数量不多，完全够用。配平计算都是简单线性计算，运行很稳定。

可以优化的地方也不少：

把重复的输出格式封装成工具方法，简化主类；

优化冒泡排序，保证同重量货物顺序更稳定；

加单元测试和日志，覆盖更多测试场景；

扩展货舱、货物、旅客的增删功能；

细化异常处理，让系统更健壮。

六、整体总结与收获

这三次迭代作业，算是一次完整的面向对象编程实践。从一个简单的小程序，慢慢迭代成结构清晰、功能完整、贴近真实业务的更加完整的代码组，我真正体会到了迭代开发的意思：一点点加功能、一步步优化，持续完善。

设计上，我学会了怎么按单一职责拆类，分清组合和聚合，彻底告别面向过程的思路；编码上，规范了手写算法、输入校验、格式输出的习惯，解决了很多常见小坑；业务上，也了解了航空配载、重心平衡的基础知识，明白程序要贴合真实业务，不能只追求功能实现。通过三次作业的完成，我对编译环境也是愈发熟悉慢慢的会运用自动生成，让我的编译速度得到提升，而且我现在的打字速度也是一点点的变快，虽然还不能完全盲打，但是比最初来的时候有了明显的变化。

当然我也知道自己还有不足，比如代码优化、算法效率、工程化思维都还需要加强。之后我会继续学设计模式、代码重构、单元测试，努力写出更规范、好维护、易扩展的代码。有些时候不知道该用哪种方法会让代码的总体感官跟简洁明了，总是第一时间想到什么方法就选择用这个方法，不会去进行方法的变更，这些地方还需要我逐步提升。

这三次作业循序渐进，难度一点点提升，让我在迭代和改错里把面向对象的基础打牢了，收获真的特别大。