OOP1-OOP3题集总结与SourceMonitor分析报告

一、前言
随着面向对象程序设计课程的不断深入，我逐渐从最开始的基础类设计与简单封装，发展到后期能够完成较复杂的业务逻辑设计与系统功能实现。在本次课程学习过程中，我共完成了 OOP1、OOP2、OOP3 三次题集训练，每一次题集都围绕 Java 面向对象程序设计展开，并逐步提高系统复杂度与程序设计要求。
在 OOP1 中，主要完成了基础类结构设计、对象创建以及简单业务逻辑实现，重点训练了类与对象、封装以及基本方法设计能力；在 OOP2 中，程序开始涉及更多模块之间的协作，同时加入了更复杂的逻辑判断与输入校验，对程序结构设计提出了更高要求；而在 OOP3 中，则进一步加入了重量平衡计算、乘客与货物管理等功能，使整个项目逐渐向完整系统开发方向靠近。
为了更加客观地分析程序结构质量与代码复杂度，本次作业还使用了 SourceMonitor 工具对代码进行了静态分析。通过 SourceMonitor，可以统计程序中的代码行数、语句数量、方法复杂度、调用次数、分支比例等数据，从而更加直观地观察程序结构变化以及不同题集之间的复杂度差异。
本文将结合三次题集的具体实现过程，对程序设计思路、类结构设计、功能实现以及 SourceMonitor 分析结果进行详细总结，并对自己在面向对象程序设计学习过程中的收获与不足进行反思。

二、OOP1题集分析
（一）题目分析
在第一次题集 OOP1 中，本次程序主要围绕 Java 面向对象程序设计的基础内容展开，重点训练了类与对象的创建、属性封装以及简单业务逻辑实现能力。相较于后续题集，OOP1 的整体结构相对简单，但它是整个课程后续开发的重要基础。
本次题集主要设计了 Cargo、CargoCompartment、Flight 以及 Main 等多个类，通过不同类之间的协作完成货物与航班之间的管理逻辑。在程序设计过程中，我开始尝试使用对象来描述现实中的实体，例如使用 Cargo 类表示货物对象，使用 Flight 类表示航班对象，并通过 CargoCompartment 类完成货舱管理。
在类设计方面，本次题集主要采用了封装思想。程序中大部分成员变量均设置为 private，并通过构造方法以及 getter、setter 方法对数据进行访问与修改。这种方式能够有效保证对象数据安全，同时提高程序结构清晰度。
例如，在 Flight 类中，主要负责保存航班信息以及对应货舱对象；Cargo 类则主要负责记录货物重量、编号等基本信息；CargoCompartment 类负责完成货物存储与管理功能。通过多个类之间的协作，程序已经初步具备面向对象程序设计的基本特征。
从程序实现角度来看，本次题集的功能逻辑相对简单，复杂度较低，因此程序整体可读性较好。在 SourceMonitor 的统计结果中，可以看到程序的整体复杂度并不高，说明当前程序主要以基础逻辑为主，还未出现大量复杂分支结构。
同时，在本次题集中，我也开始接触类之间的关系设计问题。例如，某些类之间存在聚合关系，一个对象内部会引用另一个对象。这让我对面向对象中的“对象协作”有了更深理解，而不仅仅停留在单个类的编写层面。
通过 OOP1 的练习，我逐渐掌握了 Java 面向对象程序设计中的基础语法与开发思路，也为后续更复杂题集的实现打下了基础。
（二）类图分析

从 OOP1 的类图可以看出，本次程序主要采用了基础面向对象设计思想，整体结构较为简单，重点在于类之间的协作关系与基本对象封装。
在本次项目中，系统主要包含 Cargo、CargoCompartment、Flight、Main 等核心类。其中 Cargo 类主要用于表示货物对象，负责保存货物的基本信息；CargoCompartment 类用于表示货舱，并负责对货物进行管理；Flight 类用于表示航班信息；Main 类则作为程序入口，负责整体流程控制与功能调用。
从类之间的关系来看，CargoCompartment 与 Cargo 之间属于聚合关系，一个货舱中可以包含多个货物对象；Flight 与 CargoCompartment 之间则体现了“整体与部分”的关系，一个航班对应一个货舱对象。这种设计方式体现了面向对象中的“对象组合”思想。
在类职责划分方面，各个类的功能相对清晰：
1.实体类主要负责数据封装；
2.管理类负责逻辑处理；
3.Main 类负责系统运行流程。
整体来看，OOP1 的类图结构较为基础，但已经初步体现了面向对象程序设计中的封装性与模块化思想。通过本次题集，我对类的创建、对象之间的关系以及基本系统结构设计有了更深入的理解。
（三）SourceMonitor总体复杂度分析

根据 SourceMonitor 的分析结果，OOP1 项目整体包含多个 Java 文件，总代码行数约为 157 行，Statements 为 96，整体规模相对较小，说明程序仍处于基础开发阶段。
从复杂度数据来看，项目的 Max Complexity 为 7，Avg Complexity 为 1.53，说明程序中虽然存在一定逻辑判断，但整体复杂度仍然较低，大部分方法结构较为简单。
此外，项目中的 Avg Depth 与 Max Depth 数据也说明程序嵌套层数并不深，代码整体可读性较好，逻辑结构较清晰。
总体来看，OOP1 更偏向于基础面向对象结构训练，重点在于类设计与对象协作，而不是复杂算法实现。因此，当前阶段程序复杂度较低属于正常现象。
（四）文件详细分析

从文件详细分析结果来看，Main.java 的复杂度明显高于其他类，说明当前程序中的大部分业务逻辑与流程控制仍集中在主程序中。这种设计虽然在小型项目中实现较为方便，但随着系统功能增加，Main 类会逐渐变得臃肿，从而影响代码可维护性。
相比之下，Cargo.java、Flight.java 等实体类复杂度较低，说明这些类主要用于数据封装，类职责相对单一，符合面向对象程序设计中的单一职责原则。
此外，从 Calls 数据可以看出，Main.java 与其他类之间存在较多方法调用关系，这说明程序已经开始形成多个对象之间的协作结构，而不再是单纯的过程式编程。
整体来看，OOP1 虽然系统规模较小，但已经能够体现基础面向对象程序设计思想，并为后续更加复杂的系统结构设计打下基础。
（五）采坑与问题分析
在第一次作业开发过程中，我遇到的最大问题是代码结构混乱。由于当时对面向对象设计思想理解还不够深入，因此大量逻辑都直接写在 Main 类中。随着功能增加，Main 类越来越臃肿，后期调试也变得困难。
此外，在输入处理阶段，也曾因为 Scanner 读取字符串与数字混用而导致输入异常。例如 nextInt() 读取后换行符未处理，导致后续 nextLine() 读取失败。后续通过统一输入逻辑解决了这一问题。
另外，在测试阶段还曾出现边界数据处理错误。例如某些输入为空或者数据超出范围时，程序无法正常运行。这让我意识到，程序不仅需要完成正常功能，还必须考虑异常输入情况。
（六）改进方向
后续开发中，我认为需要进一步降低 Main 类复杂度，将业务逻辑逐步拆分为独立模块。同时可以增加更加完善的异常处理机制，提高程序健壮性。
此外，也可以通过增加注释与规范命名方式提高代码可读性，并进一步优化类之间的协作关系，使系统结构更加清晰。

三、OOP2题集分析
（一）题目分析第二次题集在第一次基础上进一步扩展了系统功能，新增了输入校验、货舱管理以及装载调度等模块。相比 OOP1，本次作业的业务逻辑明显更加复杂。在本次开发过程中，我开始逐渐意识到类职责划分的重要性。程序不再只是简单的数据封装，而是需要多个模块之间共同协作完成系统功能。
（二）类图分析

OOP2 在 OOP1 的基础上进一步扩展了系统结构，整体类数量明显增加，程序逻辑也更加复杂。本次项目重点加强了对象协作关系以及功能模块划分。
本次系统主要包含 Cargo、CargoCompartment、Flight、Position、LoadDispatcher、InputValidator、Main 等多个类。其中：
1.Cargo 类用于描述货物对象；
2.Position 类用于表示货物位置；
3.CargoCompartment 类负责货舱管理；
4.Flight 类负责航班信息管理；
5.InputValidator 类用于输入合法性验证；
6.LoadDispatcher 类用于货物装载逻辑处理；
7.Main 类作为程序入口控制整体流程。
从类之间关系来看：
1.CargoCompartment 与 Cargo 之间属于聚合关系；
2.Flight 与 CargoCompartment 之间属于关联关系；
3.LoadDispatcher 会调用多个对象完成装载逻辑，因此与多个类存在依赖关系；
4.Main 类负责协调各个功能模块运行。
相比 OOP1，本次项目最大的特点是增加了功能控制类与验证类，使程序结构更加模块化。程序不再将所有逻辑集中在 Main 类中，而是将不同职责分散到不同类中，从而提高了代码可维护性与可扩展性。
此外，从类图中还能够发现：
各个类之间的职责划分更加明确；
对象之间的协作关系更加复杂；
系统开始体现“高内聚、低耦合”的设计思想。
总体来看，OOP2 相较于前一次题集，在面向对象设计方面有了明显提升，不仅增加了类之间的关联关系，也进一步提高了程序整体结构的合理性。

（三）SourceMonitor总体复杂度分析

从 SourceMonitor 的统计结果可以发现，OOP2 项目整体规模明显增加，类数量、代码行数以及方法调用次数均有明显提升。其中 Main.java 与 LoadDispatcher.java 的复杂度较高，说明程序核心逻辑主要集中在装载调度与流程控制部分。尤其是 LoadDispatcher.java，其 Max Complexity 达到7，说明程序中已经开始出现较多条件判断与复杂逻辑结构。
（四）文件详细分析。

Cargo.java、Position.java 等实体类复杂度较低，说明这些类主要负责数据封装。而 LoadDispatcher.java 复杂度较高，说明该类中存在较多业务判断与流程控制逻辑。同时 Main.java 中也存在大量方法调用关系，反映出系统模块之间的协作程度正在提高。此外，InputValidator.java 的出现也说明程序开始逐渐加入输入校验机制，系统结构比 OOP1 更加规范。
（五）采坑与问题分析在开发过程中，我逐渐意识到 Main 类不应该承担过多业务逻辑。最初我将大量调度逻辑直接写在 Main 类中，导致程序结构混乱。后续才逐渐将逻辑拆分到独立模块中。此外，在输入处理阶段，也曾出现 Scanner 输入异常与边界条件判断错误等问题。例如输入非法字符时程序会直接报错，这让我意识到程序需要增加更加完善的异常处理机制。
（六）改进方向未来可以进一步降低 Main 类与业务逻辑模块之间的耦合，同时继续优化 LoadDispatcher 中的复杂逻辑。此外，还可以通过增加更多工具类与辅助类，提高程序结构清晰度。

四、OOP3题集分析
（一）题目分析
第三次题集在前两次基础上进一步扩展系统功能，新增了 Passenger、Luggage 以及 WeightBalanceCalculator 等模块。系统已经逐渐形成较完整的航空配载管理结构。相比前两次作业，本次程序不仅需要完成数据管理功能，还需要进行更加复杂的重量平衡计算，因此整体逻辑复杂度明显提升。
（二）类图分析

OOP3 是三次题集中结构最复杂的一次，系统功能进一步扩展，类之间的关系也更加丰富。本次项目重点体现了面向对象中的继承、多态以及模块化设计思想。
本次系统主要包含 Cargo、CargoCompartment、Flight、Passenger、Luggage、WeightBalanceCalculator、InputValidator、LoadDispatcher、Main 等多个核心类。
其中：
1.Cargo 类用于描述货物信息；
2.Passenger 类用于表示乘客对象；
3.Luggage 类用于表示行李信息；
4.CargoCompartment 类负责货舱管理；
5.Flight 类负责航班信息；
6.WeightBalanceCalculator 类负责重量平衡计算；
7.InputValidator 类负责输入验证；
8.LoadDispatcher 类用于货物装载逻辑处理；
9.Main 类负责程序整体运行流程。
在类关系方面：
1.Flight 与 CargoCompartment 之间存在关联关系；
2.Passenger 与 Luggage 之间体现了对象包含关系；
3.WeightBalanceCalculator 会调用多个类中的数据完成计算，因此与多个类存在依赖关系；
4.Main 类负责整个系统模块之间的协作。
与前两次题集相比，OOP3 的系统结构明显更加完整，功能划分更加细致。特别是 WeightBalanceCalculator 类的加入，使程序开始涉及较复杂的业务逻辑处理，因此该类在复杂度分析中也表现得更高。
此外，本次项目还进一步加强了程序的模块化设计：
1.数据类负责信息保存；
2.管理类负责逻辑控制；
3.工具类负责验证与计算；
4.主程序负责整体调度。
这种结构设计能够有效降低类之间的耦合度，提高代码可读性与后期维护能力。
总体来看，OOP3 已经不仅仅是基础面向对象练习，而是逐渐接近一个小型系统的结构设计。通过本次题集，我对类之间关系设计、模块划分以及复杂业务逻辑处理有了更加深入的理解。
（三）SourceMonitor总体复杂度分析

相比 OOP2，OOP3 项目整体复杂度进一步提高。尤其是 WeightBalanceCalculator.java 的复杂度达到9，成为整个系统中最复杂的模块。此外，Calls 数量明显增加，说明程序中类之间的协作关系更加复杂，系统已经逐渐具备较完整的软件结构。
（四）文件详细分析

Passenger.java 与 Luggage.java 等实体类复杂度仍保持较低水平，说明系统中的数据类职责较为单一。而 WeightBalanceCalculator.java 调用次数较多，说明该模块承担了大量核心计算逻辑。同时 InputValidator.java 的复杂度也有所增加，说明程序开始更加重视输入数据合法性。整体来看，OOP3 的模块划分已经明显优于 OOP1，程序结构也更加规范。
（五）采坑与问题分析由于系统规模不断扩大，类之间调用关系也越来越复杂。在开发过程中，我曾因为模块职责划分不清导致后期修改困难。此外，在重量平衡计算过程中，也曾因为边界数据处理错误导致测试点失败。例如部分特殊输入情况下计算结果不正确，需要不断调试与修改逻辑。
（六）改进方向未来可以进一步对 WeightBalanceCalculator 中的复杂算法进行模块拆分，以降低单类复杂度。同时，也可以通过设计更加合理的数据结构，提高程序整体运行效率与可维护性。

五、三次题集综合对比分析通过三次题集的不断迭代，可以明显看出系统复杂度正在逐渐提升。在 OOP1 中，系统主要以基础类设计与简单逻辑实现为主，代码规模较小，整体复杂度较低。到了 OOP2，系统开始增加输入校验、装载调度等复杂逻辑，代码结构逐渐模块化，系统复杂度明显提升。而在 OOP3 中，随着重量平衡计算、乘客管理以及行李管理等模块的加入，程序已经逐渐形成较完整的系统结构。从 SourceMonitor 数据可以看出，三次题集中的代码行数、调用次数以及复杂度均呈上升趋势。这说明系统功能不断增加，同时也反映出程序设计能力正在逐渐提升。此外，通过不断重构与模块拆分，程序结构也逐渐从最初的大量逻辑集中于 Main 类，转变为多个模块协作的结构。在最初开发时，我更加关注“功能能否运行”；而在后续开发中，我开始更加关注“程序结构是否合理”“类职责是否清晰”以及“代码是否便于维护”。这种思维变化也是本阶段学习中最大的收获之一。

六、课程学习总结与反思
通过本阶段三次作业的迭代开发，我对 Java 面向对象程序设计有了更加深入的理解。相比最初只关注功能实现，现在更加重视类职责划分、模块结构设计以及代码可维护性。在不断调试与修改过程中，我逐渐意识到，一个良好的系统不仅需要正确实现功能，更需要清晰的结构与合理的模块划分。通过多次重构与优化，我的代码组织能力、问题分析能力以及调试能力都得到了明显提升。同时，我也更加理解了面向对象程序设计中的封装思想与职责划分原则。此外，我也意识到自己在复杂系统设计、算法优化以及异常处理方面仍存在不足。未来还需要继续学习设计模式、软件工程思想以及更加规范的项目开发流程。总体而言，本阶段三次作业不仅提升了我的 Java 编程能力，也让我对面向对象程序设计思想有了更加深刻的认识。对于课程本身，我认为通过多次迭代开发的方式进行训练非常有效。因为相比一次性完成大型项目，逐步增加系统复杂度更有利于理解面向对象设计思想。同时，通过 SourceMonitor 等工具对代码进行分析，也让我更加直观地认识到程序结构的重要性。