航空器配载与货运管理系统——从基础装载到载重平衡的三次迭代总结

一、前言

面向对象设计与构造课程第一单元以“航空器配载与货运管理”为主线，设计了三次递进式作业：从最基础的单货舱重量排序装载，到多货舱独立管理与智能分配，再到集成旅客行李并执行严格的载重平衡计算。整个过程模拟了航空货运地面保障的核心业务链，让我深刻体会到软件工程中从简单到复杂、从功能实现到鲁棒性保障的演进路径。

知识点覆盖全面：第一次作业侧重于Java基本语法（类定义、数组、循环、格式化输出）和自写稳定排序算法；第二次作业引入了组合与聚合关系、多对象协作、位置网格建模以及稳定排序的工程实现；第三次作业增加了旅客与行李的组合建模、基于力矩的配平物理计算、全面的输入合法性校验和防御性编程。题量上，代码行数从约150行增长至400行，类的数量从4个增加到10个，难度显著递增。尤其是第三次作业要求在任何非法输入下都能给出准确提示并安全终止，对程序的鲁棒性和细节把控能力提出了极高要求。

这三次作业不仅巩固了Java语言基础，更让我对面向对象设计中的单一职责原则（SRP）、组合与聚合的区别、依赖关系的管理有了实践层面的理解。本文将从设计与分析、采坑心得、改进建议和总结四个方面，全面复盘迭代过程中的代码错误、设计不足及改进思考。

二、设计与分析

第一次作业：基础货运配载模块

需求简述：输入航班号、最大载重及多件货物，要求按重量从高到低输出货物信息，计算总重并判断是否超载。这是最简化的业务模型，核心挑战在于类的划分和排序算法的自写实现。

类结构设计：

复杂度分析（模拟SourceMonitor）：CargoSorter.sortByWeightDesc循环复杂度v(G)=3（双重for+if），Essential Complexity ev(G)=1，表明无深层嵌套，逻辑简单。LoadManifest构造方法v(G)=2（循环内一if），Design Complexity iv(G)=2，模块间耦合低。整体平均方法复杂度OCavg约1.2，代码健康度较高。

存在的代码不足：输入读取存在隐患，Scanner.nextInt()后直接nextLine()读取字符串，若未额外处理换行符，会导致字符串读入空行。虽在本次作业中通过增加额外的nextLine()规避，但缺乏统一的输入处理机制。排序算法虽稳定，但未显式保障相等元素顺序，仅依赖冒泡特性，一旦被误改，稳定性可能丢失。主类中直接处理输入和输出，未进一步分离IO职责，主类稍显臃肿。超载后直接停止装载，后续货物信息丢失，未给出统一提示，用户可能误认为数据不完整。

第二次作业：多货舱管理与重量排序装载

需求简述：飞机分多个货舱，每个货舱有独立ID、最大载重及由行列网格构成的位置。货物需指定目标货舱，系统按货物重量降序逐一尝试装载，若导致目标货舱超载则拒绝并提示失败；最终输出每个货舱的装载状态及航班整体最大起飞/业载重量对比。

类结构设计：

组合与聚合的实现细节：货舱与位置为组合关系，在CargoCompartment构造器中内部生成Position对象，外部无法直接创建位置关联到货舱。货舱与货物为聚合关系，货物可先实例化再通过addCargo()加入，货物对象的生命周期独立于货舱。这种设计使得货物可以灵活分配到不同货舱。

设计缺陷与代码错误：排序稳定性隐患，最初实现的冒泡排序仅依赖“等重不交换”来保证稳定性，但在对ArrayList进行set操作时，由于直接修改了同一对象引用，并未破坏原始列表的映射关系。然而实际调试中发现，当重量完全相等的货物较多时，装载顺序偶尔与输入顺序不符。原因为货物对象作为键存入HashMap时，若hashCode和equals未重写，则依赖对象地址，可能导致查找不稳定。后来通过使用原始列表的索引映射解决了问题，但暴露出对Java集合框架底层机制理解不足。输出顺序混乱，装载结果需按排序后的货物顺序输出，而货舱统计应按货舱输入顺序输出。初版代码中，我错误地在货舱统计时也遍历了排序后的货物列表，导致与预期格式完全不符。正确做法是：排序结果仅用于装载决策和货物输出，货舱统计则使用flight.getCompartments()（按添加顺序维护的列表）。校验逻辑流于形式，InputValidator类虽然定义了校验方法，但在主流程中并未真正调用它们来终止程序，仅进行了范围判断打印，未能阻止后续错误代码的执行。这与第三次作业的强制终止形成鲜明对比，反映出防御性编程意识的欠缺。超载处理不完整，在装载失败时，原代码在输出“失败 (超载)”后即跳出循环，导致后续货物未再尝试装载。正确做法应是继续尝试装载后续货物，而不是中断整个装载流程。

复杂度分析：LoadDispatcher.sortCargos因增加了索引映射和额外判断，v(G)保持3但ev(G)轻微升高至2，整体仍属简单。主装载循环v(G)=2，线性处理。

心得：组合与聚合的区别在实际编码中通过对象的创建位置和所有权清晰体现。聚合的灵活性带来便利，但也要求更谨慎地管理对象引用，避免在排序或查找中出现不一致。同时，输出顺序的精确控制暴露出我在需求分析阶段对细节关注不足的弱点。

第三次作业：配平计算与增强鲁棒性

需求简述：在第二次作业基础上引入旅客（标准体重75kg+行李）和行李作为旅客的组成部分，并增加前/后货舱力臂参数，进行全机重量、力矩、重心及%MAC计算，评估重心是否在安全范围（25%-38%）内。同时，所有输入数值必须经过严格合法性校验：负数输出“数值不能为负数！”并终止；超范围输出“输入必须在X到Y之间！”并终止；超容量则输出具体舱位警告并终止。

类结构设计：

关键错误与不足：校验顺序错误导致错误提示，在读取前舱货物件数frontCargoCount时，原代码仅进行了范围校验validateRangeInt(0, totalCargo)，如果该值为负数，则输出“输入必须在0到...之间”，而正确预期应为“数值不能为负数！”。错误根源在于没有首先执行非负判断。修正方法：先调用validateNonNegativeInt再调用validateRangeInt，形成层次化校验。这种错误提示的不准确，在实际业务中可能误导用户。货物输出顺序再次偏离，题目要求在输出舱单货物清单时，按货物装载的原始顺序列出，但我却错误地使用了LoadDispatcher.sortCargos排序后的列表。排序只是为了满足内部调用要求，不应影响最终呈现的顺序。这个缺陷直接导致了配平评估部分结果的输出顺序与预期不符，属于典型的需求理解偏差。过度工程化尝试，为了解决某个校验问题，我曾引入readInt方法，内部使用hasNextInt()判断输入是否为整数，若不是则直接输出错误并退出。但这一改动引入了新问题：当输入是合法整数但值非法时，hasNextInt()仍返回true，导致后续校验逻辑执行，但多了一层不必要的判断，增加了代码路径的复杂性和维护难度。最终这一过度设计被移除，回归到直接scanner.nextInt()配合校验方法的方式，使代码更清晰。浮点常量精度未刻意控制，空机力臂常量定义为16.25，输出时使用%.1f格式自动显示为16.3，但最初我曾在代码中直接写16.3，导致后续CG计算出现微小偏差，在边界条件下可能影响安全评估的准确性。使用原始精确值（16.25）并在输出时四舍五入，是保证计算结果正确的最佳实践。主类职责过重，主方法中包含了大量的输入读取、对象创建、装载循环和校验调用，代码超过150行，明显违反了SRP。合理的做法是将输入解析和对象构建抽取到专门的InputParser或FlightBuilder类中，主类仅负责协调流程。

复杂度与耦合：WeightBalanceCalculator.generateLoadSheet虽为线性过程，但因为承担了计算和输出双重职责，方法内耦合度偏高。理想做法是将计算逻辑与输出分离，计算返回一个LoadSheet数据对象，再由专门的LoadSheetPrinter负责格式化输出，进一步提升可扩展性。

心得：第三次作业让我领教了“细节是魔鬼”。校验顺序、输出顺序、常量精度这些看似微不足道的点，任何一环的疏忽都会导致整个系统输出错误。而且，过度设计往往比简单直接更危险，保持代码的简洁和意图明确是防御性编程的重要原则。

三、采坑心得

输入读取的隐形陷阱：三次作业反复遇到Scanner读取混合类型时的换行符残留问题。使用nextInt()或nextDouble()后，行尾换行符未被消耗，导致随后的nextLine()读入空字符串。最初我总在读取整数后加一条scanner.nextLine()来解决，但这种方式散布在主流程中，极易遗漏。根本原因是缺乏对Java I/O流机制的深入理解，以及没有设计统一的输入处理模块。正确的做法是封装一个InputReader类，统一管理所有读取操作，内部处理掉缓冲问题，对外提供干净的数据接口。

排序稳定性的表象与实质：冒泡排序本身是稳定的，但在第二次作业的自写排序中，当货物重量相等时，仅凭“不交换”并不能保证绝对稳定，特别是当列表在排序前已经经过其他变换时。后来通过显式记录原始索引并与当前索引比较来决定交换，才真正实现了与输入完全一致的顺序保持。这个坑让我认识到：理论上的算法稳定性必须结合具体数据结构的实现来验证，引用复制、集合操作等都可能破坏原有的顺序。

组合与聚合的错位：在最初设计第二次作业时，我曾试图将货物也作为组合在货舱内创建，这导致货物与舱位强绑定，无法灵活分配。后来纠正为聚合，但又在CargoCompartment中直接暴露了List的内部引用，存在外部直接修改集合的风险。正确做法是返回一个不可修改的视图或副本，如Collections.unmodifiableList。这一错误让我在第三次作业设计旅客与行李组合时格外注意封装性，确保行李只能在旅客内部创建。

校验逻辑的优先级混乱：第三次作业中的校验教训深刻：业务系统中校验必须遵循“基础合法性→业务范围→业务规则”的层级。先确保数据是非负数，再检查是否在允许区间，最后判断是否满足容量等约束。如果将范围校验放在前面，遇到负数就会给出错误的范围提示，造成用户困惑。这种校验链的设计思想在工程中至关重要。

输出格式的毫米级精确：第二次作业输出货物装载结果时，要求失败信息中括号内包含空格：“失败 (超载)”。我曾在代码中写成“失败(超载)”，导致全错。第三次作业舱单的标题“=======”数量、正文中空格的分布、“.”的位置，都必须与样例完全一致。任何一个字符的差异都会被判错。这让我养成了提交前逐字符比对样例输出的习惯，但也反映出课程评测对格式依赖过重的问题，未能考察程序的逻辑容错能力。

过度防护与代码简洁性的平衡：在解决第三次作业某个输入校验问题时，我引入了hasNextInt()来捕捉非整数输入，并自作主张地输出一条通用错误信息。但这一改动非但没有解决问题，反而让代码路径变得复杂，还干扰了真正的错误定位。最终发现只需调整已有校验方法的调用顺序即可。这表明，在没有明确需求的情况下，不应随意增加“预防性”功能，保持代码最小化、目标明确才是明智之举。

常量管理的随意性：第三次作业的物理常量（力臂、重量等）曾一度散落在计算方法的局部变量中，导致重复定义且难以维护。后来虽然提取为静态常量，但仍然集中在WeightBalanceCalculator类中，与具体飞机型号绑定。若未来要适配不同机型，这些常量需要重构为可配置的。缺少对“变化点”的前瞻性设计，是这次作业暴露的不足之处。

四、改进建议

构建统一的输入处理层：三次作业的主类都直接操作Scanner，建议封装InputReader类，提供readInt(min, max)、readDouble(min, max)、readString()等方法，内部处理类型转换、缓冲问题和立即校验，大幅简化主流程并提高可读性。

强化实体类的不可变性：Cargo、Luggage等实体，一旦创建其属性应不可变（通过final字段和只提供getter实现），避免后续操作中意外修改导致状态不一致。尤其是聚合关系中的货物，其重量被更改可能破坏货舱已计算的重量。

排序算法的策略化：虽然题目禁止继承和多态，但若解除限制，应将排序算法抽象为接口，通过策略模式注入，方便替换。在现有约束下，至少将排序逻辑从调度类中独立为一个纯算法工具类，并支持升/降序配置。

分离计算与输出逻辑：WeightBalanceCalculator目前既负责复杂计算又负责格式化输出，违反SRP。应拆分出一个LoadSheetPrinter，接收计算结果对象LoadSheet，负责渲染舱单。这样计算部分可单独测试，输出格式可灵活调整。

引入校验链模式：将多个校验规则（非负、范围、超载等）设计为可串联的校验器，主流程仅需调用链头，每个校验器失败即抛出特定异常并终止。这比当前序列化的if+exit更清晰，也易于扩展新规则。

加强单元测试覆盖：虽然作业以在线评测为主，但若自己编写JUnit测试，针对排序稳定性、超载边界、重心计算边界等场景构建测试用例，能更早发现逻辑错误，减少对评测系统的依赖。在后续课程中应强化测试驱动开发的实践。

类职责再细分：Flight类在第二次作业后变得庞大，既管理货舱列表又管理旅客列表，还负责总重计算和超限判断。可考虑将重量统计职责交给独立的WeightCalculator，将超限判断交给OverloadEvaluator，使Flight回归纯数据容器的角色。

五、总结

通过本阶段三次作业，我完成了一个小型航空配载系统的全迭代开发，深切感受到面向对象设计在应对需求变化和复杂度增长时的威力。

核心技能收获：扎实掌握了Java基础语法、集合框架及控制台I/O，能够独立编写中等规模应用程序。深刻理解了单一职责原则，并在类设计中有意识地运用，每个类只承担一个变化的原因，使得系统结构清晰。弄清了组合与聚合的本质区别：组合强调生命周期绑定，聚合强调独立存在和灵活组装，这一认知直接影响代码的构造方式和依赖管理。学会了自写稳定的排序算法，并认识到理论稳定性与工程实现的差距。提升了防御性编程水平：懂得设计前置校验、明确错误输出，让程序在异常面前举止得当。锻炼了从错误输出倒推代码问题的调试能力，尤其是对格式、顺序、边界条件的敏感度大大提高。

仍需加强的领域：设计模式的应用经验几乎为零，未来需在项目中刻意练习策略、工厂、责任链等模式。单元测试和自动化测试技能薄弱，应系统学习JUnit和Mock框架。对Java高级特性如反射、注解、流式编程的了解不够，限制了代码的灵活性和表达能力。代码重构和优化意识有待提升，经常是功能实现后即满足，缺乏审视和改进的主动性。

对课程的建议：可在每次作业后安排代码评审环节，让同学们相互阅读代码，指出设计问题和改进点，这比单纯看评测结果更有收获。
总而言之，航空器配载系列作业不仅是一次编程训练，更是一次小型软件工程的实践。从第一版的简单实现到第三版的全面鲁棒，每一行代码的增删改都映射着对设计原则和业务逻辑的再理解。这段经历让我明白：好的程序不是一次写成的，而是在不断试错、反思和重构中打磨出来的。未来我将继续强化面向对象的内功，在更复杂的系统中追求代码的简洁、健壮和优雅。