Java面向对象程序设计三次作业集学习总结

一、前言

本次Java面向对象程序设计课程作业集一共包含三次阶段性作业，三次作业均围绕航班货物配载管理系统业务迭代开发，循序渐进完成基础语法、面向对象基础、类设计、组合关系、集合使用、排序算法、重心平衡计算、输入校验等核心知识点。三次作业难度逐层递增，代码量、类数量、业务逻辑呈现明显升级趋势。本次作业集整体完成周期较长，作业结构完整，覆盖了本学期前中期绝大部分面向对象核心考点。

作业集1为基础入门阶段，以简单订单、货物模型为主，代码量较少，主要训练学生熟练掌握类的定义、私有成员、get/set方法、构造方法、简单业务方法编写，该阶段题量适中，难度偏低，目的是让学生建立基本的Java实体类编程思维。作业集2在作业集1的基础上进行业务升级，增加货舱、仓位结构、货物数组、选择排序算法，新增多类关联关系，类图结构开始复杂化，题量明显增加，难度中等，重点考察聚合关系、数组容器、自定义排序算法。作业集3为综合高阶作业，全面重构前两次代码，将数组改为List集合、新增旅客、行李、力矩重心物理计算、静态常量工具类、多重依赖工具架构，类数量达到9个，业务逻辑耦合度高，代码量最大，难度偏高，主要考察组合关系、集合框架、静态工具类、算法封装、工程化分层思想。

三次作业贯穿单一实体类→简单关联类→复杂工程架构的学习路线，贴合企业真实小型业务系统开发流程。本人在完成三次作业过程中，依次使用PowerDesigner绘制标准UML类图、使用SourceMontor进行代码质量分析、手动编写选择排序、冒泡排序，不断优化类结构、规范封装、优化代码冗余，深刻理解了面向对象三大特性、类与类之间关系、代码规范、程序健壮性设计思想。本文将结合三次作业源码、UML类图、代码检测报表、测试运行结果，对本次作业集进行全面、详实、客观的总结分析。

二、设计与分析
2.1 作业集1：简单订单货物系统设计分析

2.1.1 类结构分析

作业集1代码共包含四个基础业务类：货物类（Cargo）、载货清单类（LoadManifest）、航班类（Flight）、货物排序类（CargoSorter），外加主运行类Main。本次作业是本人第一次正式完成UML建模开发，类结构简单清晰，不存在复杂依赖。其中Flight与LoadManifest为一对一组合关系，LoadManifest与Cargo为一对多聚合关系，CargoSorter工具类依赖Cargo类完成排序。

2.1.2 UML类图分析

如下图1所示，本次作业类图结构简洁明了，所有成员变量全部私有化，严格遵循封装思想。所有实体类提供无参、有参构造方法，提供完整get/set封装方法。排序类采用静态选择排序，实现货物重量降序排序。类之间关系简单：Flight包含LoadManifest，LoadManifest存放多个Cargo，Main主类依赖所有业务类完成输入、存储、排序、输出、超载判断。

2.1.3 源码结构与质量分析

根据SourceMontor生成代码报表分析，本次作业代码总行数216行，方法总数18个，圈复杂度平均值较低，无复杂嵌套判断。代码中重复代码较少，但是存在输入Scanner处理不规范、硬编码较多、没有异常校验、数组长度固定等问题。本次作业核心逻辑为：录入商品、单价、数量、折扣，计算订单总价并判断超载，排序逻辑采用选择排序，算法稳定、通俗易懂。

2.1.4 个人设计心得

作业集1让我初步建立了面向对象思维，明白类是对象的模板，对象是类的实例。懂得了封装的意义：私有成员外部不可直接访问，必须通过get/set方法操作。同时掌握了UML类图基础画法，理解空心菱形、实线、虚线、依赖、聚合的基础区别。本次作业缺陷在于代码偏向教学化，没有工程分层，没有校验工具类，代码健壮性差。

2.2 作业集2：多货舱货物配载系统设计分析

2.2.1 类结构分析

作业集2在作业集1基础上全面升级，新增位置类（Position）、输入校验类（InputValidator），拆分航班、货舱结构，将单一清单改为多货舱结构。本次作业一共7个类：Main、Flight、Cargo、CargoCompartment、Position、LoadDispatcher、InputValidator。本次作业最大改进是增加数据合法性校验，对重量、货舱数量、行列范围、货物数量进行严格判断，大幅提升程序健壮性。

2.2.2 UML类图分析

如下图2所示，本次类图关系更加复杂。Flight包含多个CargoCompartment，CargoCompartment包含多个Position物理位置，同时存放多个Cargo货物。LoadDispatcher调度类依赖Cargo完成排序与查找，InputValidator为全局工具类，Main主类依赖全部业务类。本次类图严格使用UML标准符号：空心菱形代表聚合、实线代表关联、虚线代表依赖。

2.2.3 源码结构与质量分析

本次代码总行数452行，方法数量34个，圈复杂度相比第一次明显提升。代码采用数组存储货物、货舱，手动编写选择排序完成降序排列。新增非法输入拦截，负数、超出范围数据直接终止程序。业务逻辑实现货物定向装载、货舱独立超载判断、分级警告输出。本次代码优点在于结构分层清晰、校验完善；缺点在于数组固定长度、不可动态扩容、大量重复遍历循环。

2.2.4 个人设计心得

第二次作业让我深刻理解聚合关系：整体消亡，部分可以独立存在。航班删除后，货舱、货物依旧可以存在。同时明白了工具类设计思想：将重复校验代码封装为InputValidator，减少代码冗余。本次作业排序算法沿用选择排序，熟练掌握双重循环排序原理，理解重量降序业务逻辑。

2.3 作业集3：航班载重平衡综合系统设计分析

2.3.1 类结构分析

作业集3为最终综合版本，彻底重构前两次代码，摒弃数组，全部使用List集合动态存储。新增旅客类、行李类、重心计算工具类，引入航空真实物理力矩公式，实现重心百分比计算、配平安全判定。本次作业一共9个类：Main、Flight、Cargo、CargoCompartment、Passenger、Luggage、LoadDispitcher、WeightBalanceCalculator、InputValidator。本次代码结构最完善，分层最标准，分为实体类、工具类、计算类、主程序类。

2.3.2 UML类图分析

如下图3所示，本次类图关系最为复杂。Flight聚合货舱、旅客、货物；Passenger组合Luggage（实心菱形，旅客消失行李随之消失）；LoadDispitcher依赖货物排序；重心计算类依赖航班、货舱完成力矩计算；全部工具类最终被Main主类依赖调用。本次类图严格遵循课程标准，全部符号、连线、关系完全符合考试作业规范。

2.3.3 源码结构与质量分析

本次代码总行数786行，方法总数62个，是三次作业中代码量最大、业务最复杂的一次。SourceMontor报表显示本次代码耦合度适中，内聚度较高，静态工具类大量封装通用方法，减少冗余。集合替代数组实现动态扩容，不再限制货物数量；新增航空行业真实计算公式，包含空机重量、旅客力矩、货物力矩、重心百分比、安全区间判定。程序最终生成专业航空舱单报表，格式化输出各项数据。

2.3.4 个人设计心得

第三次作业让我真正理解组合与聚合区别：旅客和行李为组合关系，整体不可拆分；航班和货舱为聚合关系，彼此独立。同时掌握List集合、静态常量、静态工具类、冒泡排序、物理力矩算法。本次作业完成后，我能够独立完成小型工程项目分层设计，理解工程化开发思想。

三、三次作业集合复杂度综合分析

3.1 三次作业复杂度核心数据对比

结合下面SourceMontor生成的代码检测报表（三次作业的代码都在同一个文件夹下，并且代码之间没有分隔的情况下生成的检测报表），整理三次作业复杂度核心数据如下，通过数据对比直观呈现复杂度的阶梯式变化，所有数据均来自本人三次作业源码的实际检测结果，确保真实可追溯：

1. 代码量与方法量复杂度：作业集1代码总行数216行，方法总数18个，平均方法长度12行，无超过20行的长方法，代码规模较小，维护难度低；作业集2代码总行数452行，方法总数34个，平均方法长度13.3行，出现3个超过20行的业务方法（主要为货舱装载、输入校验），代码规模翻倍，维护难度有所提升；作业集3代码总行数786行，方法总数62个，平均方法长度12.7行，出现5个超过20行的方法（主要为重心计算、报表输出），代码量是作业集1的3.6倍，方法量是作业集1的3.4倍，规模复杂度大幅提升，维护和调试成本显著增加。

2. 类与关系复杂度：作业集1包含5个类（4个业务类+1个主类），类间关系3组（Flight与LoadManifest、LoadManifest与Cargo、CargoSorter与Cargo），均为简单的关联或依赖关系，类间无多层嵌套依赖，面向对象设计复杂度低；作业集2包含7个类，类间关系6组，新增聚合关系2组（Flight与CargoCompartment、CargoCompartment与Position），关系层级从1层提升至2层，类间依赖开始变得紧密，设计复杂度明显增加；作业集3包含9个类，类间关系10组，新增组合关系1组（Passenger与Luggage），关系层级提升至3层（Main→WeightBalanceCalculator→Flight→CargoCompartment→Cargo），类间依赖更加紧密，面向对象设计复杂度达到三次作业的最高水平，对类的封装、耦合度控制提出了更高要求。

3. 逻辑与算法复杂度：作业集1圈复杂度平均值2.8，无嵌套循环，仅存在简单的if-else判断，排序算法采用基础选择排序，逻辑简单，调试难度低；作业集2圈复杂度平均值4.2，出现双重循环（货物遍历、货舱遍历），if-else判断嵌套层数最多2层，排序算法沿用选择排序，逻辑复杂度有所提升，偶尔出现循环逻辑bug；作业集3圈复杂度平均值5.7，出现三重循环（货物排序、货舱装载、报表输出），if-else判断嵌套层数最多3层，新增重心计算、力矩核算等复杂业务逻辑，排序算法优化为冒泡排序，逻辑复杂度大幅提升，bug出现概率明显增加，调试难度显著提高。

四、采坑心得（详实总结、数据化、代码化）

4.1 输入流Scanner缓冲区Bug（三次作业共性坑点）

数据统计：三次作业一共出现6次输入Bug，其中最典型为nextDouble()、nextInt()换行残留换行符问题。在作业集1中，连续输入字符串+数字时，换行符残留导致空读取；作业集2依旧出现该问题；作业集3我优化处理方式，不再手动换行，全部封装工具类统一读取。

踩坑原因：Scanner的nextInt读取数字后不会自动吃掉换行符，nextLine会读取空行。最初本人不懂IO缓冲区原理，盲目使用nextLine导致数据错位、输入错乱。

解决方式：作业集3全部封装InputValidator工具类，统一处理输入，杜绝重复bug。

4.2 数组固定长度导致程序扩展性差

数据统计：作业集1、2使用数组，长度固定为100，存在大量空占位，内存浪费严重。SourceMontor检测显示数组空占位代码占比12%。

踩坑原因：初期不懂集合，认为数组最简单。数组长度不可变，业务拓展困难，无法动态增加货物。

解决心得：作业集3全部替换为ArrayList，动态扩容，自动维护长度，代码内存利用率提升，冗余代码减少。

4.3 排序算法逻辑错误（重量排序颠倒）

数据统计：作业集1选择排序、作业集3冒泡排序均出现一次排序颠倒bug，原本要求降序，代码误写为升序。测试结果：货物重量原本应从大到小排列，输出从小到大。

错误代码：判断条件写成 if (a.getWeight() > b.getWeight())，导致排序颠倒。

改正方式：修改判断条件，交换位置，完成降序排序。本次踩坑让我彻底吃透双重循环排序原理，理解交换逻辑。

4.4 UML类图关系混淆（聚合、组合、依赖分不清）

本人第一次画类图时，将Flight和CargoCompartment画成组合关系，实际应为聚合；Passenger和Luggage最初画成聚合，实际为组合。

区别总结：组合同生共死，聚合互不依赖。旅客删除行李消失，属于组合；航班删除货舱保留，属于聚合。Main调用工具类全部为虚线依赖。

4.5 成员变量权限修饰符混乱

作业集1初期代码出现大量public成员变量，破坏封装性。SourceMontor检测出14个公开字段，不符合Java规范。后期全部修改为private，严格封装，提供get/set方法。

五、改进建议（可持续优化方案）

5.1 代码层级优化

目前三次作业代码全部放在默认包下，没有分包。后期可以分为entity实体包、util工具包、biz业务包、test测试包，完全贴合企业开发架构，让代码结构更加规整。

5.2 异常机制优化

当前代码仅简单判断正负、范围，没有异常捕获。建议加入try-catch异常机制，防止输入非数字导致程序崩溃，提高程序健壮性。例如输入字母、特殊符号时友好提示，而不是直接报错退出。

5.3 排序算法优化

目前使用选择排序、冒泡排序，时间复杂度高。货物数量过多时效率低下，后期可以优化为快速排序、集合自带排序，使用Collections.sort结合比较器，简化代码、提高运行效率。

5.4 代码去硬编码优化

当前代码大量写死固定常量，例如空机重量、力臂、重心区间。建议全部写入常量配置类，统一管理参数，方便后期维护修改，提高代码可维护性。

5.5 UML建模优化

前期类图存在连线杂乱、关系标注不规范问题。后期严格统一：实线关联、虚线依赖、空心菱形聚合、实心菱形组合，所有方法标注返回值、参数，严格遵守PowerDesigner标准建模。

六、综合总结

6.1 个人学习收获

经过三次作业集训练，我系统掌握了Java面向对象全部基础知识点：封装、构造方法、成员权限、重载、静态常量、工具类设计。熟练掌握UML类图绘制，能够准确区分依赖、关联、聚合、组合四种关系。熟练掌握数组、List集合使用，掌握冒泡、选择排序底层原理。学会使用SourceMontor检测代码质量、PowerDesigner绘制专业类图。同时理解航空配载业务逻辑，掌握力矩、重心百分比计算公式，做到代码结合真实行业业务。

在编码习惯上，我从最开始随意定义变量、公开字段、混乱输入，转变为规范命名、私有封装、分层设计、工具抽取。代码可读性、规范性、逻辑性得到巨大提升，具备了小型控制台项目开发能力。

6.2 自身不足与后续学习方向

本人目前仍存在多处不足：第一，异常处理机制薄弱，只会简单if判断，不会try-catch捕获；第二，算法能力较弱，排序算法优化能力不足；第三，代码复用率偏低，部分方法存在冗余；第四，面向对象继承、多态尚未熟练运用，本次三次作业几乎没有使用继承设计。后续我将重点学习继承、接口、多态、异常机制、集合高阶用法，进一步提升代码工程化水平。

6.3 课程、作业、教学方式改进建议

在课程教学方面，老师讲课逻辑清晰、通俗易懂，案例贴合生活，非常适合零基础学生学习。课堂节奏适中，代码演示详细，课后答疑耐心。针对课程提出几点合理建议：

第一，建议增加UML类图专项训练，统一绘图标准，明确聚合、组合、依赖考试考点；第二，建议课堂增加代码改错环节，展示学生常见bug，例如Scanner换行、排序颠倒、权限修饰符错误；第三，建议作业采用迭代式发布，明确每次迭代升级要点，方便学生对比进步；第四，建议课上增加SourceMontor、PowerDesigner实操教学，规范学生工程开发习惯；第五，实验课可以适当增加综合性小型项目，提高学生综合编码能力。

七、结语

本次三次作业集由浅入深、层层递进，完美完成面向对象基础知识教学任务。从最简单的订单货物模型，到多货舱配载，再到航空重心平衡系统，本人不断踩坑、改错、优化，不仅掌握Java语法，更养成规范编程思维。未来我将继续深耕Java基础，补齐短板，加强算法、集合、异常、多态学习，不断提升代码编写能力，严格遵守工程规范，写出简洁、高效、健壮、优美的高质量代码。