Java面向对象程序设计——三次作业集总结
标签： Java, 面向对象, 作业总结, 航空, 软件工程
写在前面
本次系列作业围绕 “航空器配载与货运管理系统” 展开，从最简单的单舱装载，演进到多货舱管理，再到引入旅客与基于物理力矩的载重平衡计算，完整模拟了一个小型航空信息系统的迭代开发过程。
对我而言，这不仅是自己第一次编程这种迭代类型的三次编程作业，更是一次从 “写代码” 到 “做工程” 的认知跃迁，可以说这是目前写过最复杂的代码了。在这几周中，在平时课堂上学习了 Java 的基础语法、面向对象思想、类设计原则以及工程化工具的使用，也自己私下里对一些陌生的地方进行探究和了解。
通过这三次作业，我主要掌握了以下知识与能力：
- Java 基础语法与数据类型
- 类与对象的基本概念
- 封装思想与单一职责原则（SRP）
- 类之间的关系：组合、聚合与依赖
- 集合框架（ArrayList）的使用
- 排序算法的手动实现（选择排序、冒泡排序）
- 基于物理模型的工程计算（力矩、重心）
- 输入校验与程序优化设计
- 进行总结性Blog的编写和发布
- 使用 SourceMonitor 与 PowerDesigner 进行代码与结构设计
下面，我将从自己刚接触到这个迭代式作业开始，从基础知识学习、程序结构、作业分析、Bug 分析、改进建议等方面进行全面总结。
一、Java 基础与面向对象基础学习回顾
在进入作业之前，我首先系统复习并实践了 Java 的基础语法，这也是三次作业能够顺利推进的前提。
1.1 Java 基础语法
在第一次作业中，我重点练习了以下内容：
- 数据类型：
明确了int、double、String的使用场景。例如在航班载重计算中，double是保证精度的基础。 - 变量与常量：
学会区分可变变量与final常量，第三次作业中大量使用了final static定义力臂与 MAC 参数。 - 运算符：
熟练掌握算术运算符、比较运算符与逻辑运算符，尤其在重心计算中频繁使用四则运算。 - 控制流程：
if-else用于超载判断，for循环用于遍历货物与排序，这是程序最基本的骨架。 - Scanner 输入：
从控制台读取数据是三次作业的共同入口，也让我第一次意识到输入合法性校验的重要性。
1.2 类与对象
面向对象是我在这三次作业中最大的收获之一。
- 类（Class）：
是对现实事物的抽象。例如Flight、Cargo、Passenger都是对现实中实体的建模。 - 对象（Object）：
是类的具体实例。每一次new Cargo(...)都是在内存中创建一个真实的货物对象。 - 属性与行为：
属性描述对象的状态（如重量、名称），方法描述对象的行为（如计算总重量、判断是否可装载）。
1.3 封装与职责划分
在老师的多次强调下，我逐步理解了 封装 的意义：
不让外部随意修改对象内部状态，而是通过方法进行控制。
例如我在编写过程中运用到的一些方法：
CargoCompartment不直接暴露currentWeight- 而是通过
canLoad()和addCargo()方法进行受控修改
这种设计显著降低了出错概率。
也让我逐渐形成了对封装的理解：
-封装不是简单地加 private和 getter/setter，
-而是让对象的内部状态只对“有权限的人”开放，
-并通过明确的职责方法来控制变化。
二、Complexity Metrics（复杂度分析）
为了量化代码质量，我使用老师给的资源 SourceMonitor 对三次作业进行了静态分析，重点关注以下指标：
- ev(G)：基本复杂度（结构清晰度）
- iv(G)：设计复杂度（类与方法耦合度）
- v(G)：循环复杂度（逻辑分支数量）
- OCavg：类平均复杂度
- WMC：类总复杂度
所有数据均来源于 SourceMonitor 报告，并在后文结合具体作业进行分析。
三、第一次作业：基础航空器货运配载
3.1 作业需求回顾
第一次作业是一个典型的入门级面向对象问题：
- 输入航班号与最大载重
- 输入若干货物（名称、重量）
- 按重量排序后装载
- 判断并输出是否超载
3.2 实现方式与类结构设计
本次作业共设计了 8 个类：
| 类名 | 职责 |
|---|---|
Flight |
航班信息 |
Cargo |
货物实体 |
LoadManifest |
装载清单 |
Cargozhuangzai |
装载控制 |
CargoSorter |
排序算法 |
zhuangtai |
结果输出 |
chaozhong |
判断超重状态 |
Main |
主程序 |
这一阶段，我最大的进步是：
不再把所有代码写在 main 方法中
开始尝试按职责拆分类
3.3 源码分析与复杂度
类图
复杂度
canLoad()方法逻辑清晰，v(G) 低sortWeight()使用双重循环，复杂度随数据规模增长- 类数量增加，整体更符合 SRP
4.4 踩坑与心得
-
题目理解的问题：
开始写代码的时候并没有准确的分析题目，以为它的装货功能是要实时装载，就是类似于输入一个货物，就进行一次相应的计算与判断，然后导致程序写的非常复杂，然后最后还通过不了，最后深入理解了下题目才知道要最后统一进行装货操作，进行相应的判断。 -
输入校验缺失：
初期未限制负数输入，导致非法数据进入系统，开始没有建立优化检测类，然后输入是未进行过控制的虽然当时的测验点没有多少设计输入校验的，但是为了保证程序的正确性加上了对于输入校验的相关的检测。
四、第二次作业：多货舱管理与重量排序
4.1 作业需求
在第一次基础上，系统复杂度明显提升：
- 支持多个货舱（前舱、后舱）
- 每个货舱有最大载重与位置网格
- 货物按重量降序装载
- 每个货舱独立判断是否超载
4.2 新增类与关系设计
本次作业共设计了 11 个类：
| 类名 | 职责 |
|---|---|
Flight |
航班信息 |
Cargo |
货物实体 |
LoadManifest |
装载清单 |
Cargozhuangzai |
装载控制 |
CargoSorter |
排序算法 |
zhuangtai |
结果输出 |
CargoCompartment |
货舱的装载状态 |
Position |
货舱中的一个位置 |
InputValidator |
输入校验类 |
LoadDispatcher |
进行调度操作 |
Main |
主程序 |
类关系：
- 货舱与位置：组合
- 货舱与货物：聚合
- 调度器与航班：依赖
这一阶段，我真正体会到 “类之间的关系比类本身更重要”。
4.3 源码分析与复杂度
类图
实体类
Flight：航班实体，封装了航班号、最大起飞重量 (maxWeight) 和最大业载 (maxPayload)。
Cargo：货物实体，包含名称、重量和目标货舱 ID。
CargoCompartment：货舱实体，包含容量、当前重量及位置网格，是业务逻辑的核心载体。
Position：货舱中的坐标位置，作为 CargoCompartment的组成部分。
控制与流程类
Main：程序入口，负责输入解析、对象初始化及流程串联。
LoadDispatcher：调度器，实现货物重量的降序排序逻辑。
Cargozhuangzai：装载控制器，执行具体的装载策略（查找货舱、判断能否装载、记录结果）。
zhuangtai：输出类，负责格式化打印最终状态。
辅助与工具类
LoadManifest：清单类，作为全局货物容器，避免数据散落。
chaozhong：超重判断工具，独立封装了重量比较逻辑。
InputValidator：输入校验工具，虽然代码中未完全调用，但体现了防御式编程的思想。
- 方法 v(G) 略高，主要因为逻辑集中
- 排序方法结构简单，复杂度低
- 类职责基本清晰，但仍存在输出与逻辑混合的问题
3.4 踩坑与心得
-
容量与重量混淆：
初期只判断重量，忽略位置数量限制，导致设计缺陷。 -
排序算法理解不深：
第一次写选择排序时，由于边界条件处理不当，导致数组越界异常。通过多次手工推演循环过程，最终修复。 -
对象查找效率低：
使用线性遍历查找货舱，虽可行但不优雅。
这次作业让我明白：能跑 ≠ 正确 ≠ 健壮。
五、第三次作业：载重平衡与重心计算
5.1 作业需求
这是三次作业中工程性最强的一次：
- 引入旅客与行李
- 标准体重 + 行李重量
- 基于力矩计算重心
- CG%MAC 安全区间判断（25%~38%）
5.2 新增类与设计思想
| 类名 | 职责 |
|---|---|
Passenger |
旅客（组合 Luggage） |
Luggage |
行李 |
WeightBalanceCalculator |
纯计算工具类 |
代码结构
类图
复杂度
设计亮点：
- 组合关系：旅客必然拥有行李
- 工具类：不包含状态，只提供计算方法
- 常量集中管理：所有物理参数统一定义
5.3 物理计算逻辑
重心计算分为五个步骤：
- 旅客总重量与力矩
- 货舱总重量与力矩
- 全机总重量与总力矩
- 实际重心位置
- CG%MAC 换算与安全评估
这一过程让我第一次感受到：
代码只是工具，背后的工程模型才是核心。
5.4 踩坑与心得
-
公式精度问题：初期分子分母的精度没有调整好，没有理解准确题目的具体意思，导致出来的值始终产生着一些偏差。
-
题目理解的偏差：
![image]()
题目有误的处理输出格式没有理解透彻，导致没有增加实时检测异常的功能，最后添加了一个专门检测异常值的类，用于实时检测，一旦有异常就立即停止程序，并按照题目所规定的结构输出错误的内容。 -
迭代过程中的修改问题：
这是第三次的迭代，由于前两次有部分功能在这一次的实际并没有用上，然后就会导致部分代码没有起到作用，增加了程序的复杂性，也有部分是前期结构没有完全的设计好，导致了后面改动的时候越来越难改，一旦改了前面一个类，会导致相关的类没办法运行，要再新增一个类并补全相应的功能操作来完善类与类之间的练习，代码逻辑性比较差。
六、算法学习与排序实现
三次作业中，我手动实现了两种排序算法：
- 第一次：选择排序
- 第三次：冒泡排序
通过手写算法，我真正理解了：
- 嵌套循环的执行过程
- 临时变量交换的本质
- 时间复杂度与空间复杂度的意义
这也让我对代码的结构化有了更深入的了解，完全可以在开始便把一些功能类都制作完毕，分区块，分步骤的完善程序，而不是需要哪个写哪个部分，然后把程序进一步的友善
七、工具链学习（SourceMonitor & PowerDesigner）
7.1 SourceMonitor
用于量化代码质量，帮助我发现：
- 哪些方法过于复杂
- 哪些类职责过重
- 注释率是否达标
7.2 PowerDesigner
用于建模类图，帮助我理清：
- 类之间的关系
- 系统的整体结构
工具的使用，让我的设计从“凭感觉”走向“有依据”。
八、工程素养与调试经验
通过三次作业，我逐渐形成了一套调试习惯：
- 先想清楚逻辑，再写代码
- 小步提交，逐步验证
- 构造边界数据与异常数据
- 打印中间结果辅助定位问题
这些习惯，比某一次作业的正确性更重要。
九、改进建议
9.1 对本人代码
- 拆分
Flight类，分离物理计算与信息管理 - 引入更多
final常量 - 优化排序算法的可读性
- 增加更多的注释，每次迭代都要理解自己的代码，缺少注释非常的不利于下次编写
9.2 对课程与作业
- 建议增加示例类图
- 增加代码互评环节
- 提供标准化测试数据
- 可以增加一些测试点，方便完善代码
十、总结
这三次作业，是一次完整的 “需求 → 设计 → 实现 → 验证 → 反思” 的软件工程闭环。
我从只会写 main 方法，到能设计多个类、明确职责、控制复杂度，这是思维方式的根本转变。
未来，我希望进一步学习更多相关内容，完善自己的知识体系，利用更多的实践训练来加强自己的编程思维与能力。
我相信，这些看似“多余”的工程训练，正是成为一个合格开发者的必经之路。