航空器配载与货运管理系统总结性Blog
一、前言
知识点
涉及到的知识点基本为
- java的基础语法以及类的基本构成，测试类，实体类，工具类的基本构成与作用的理解以及运用。
- 简单的设计原则，单一职责。认识到其具体实现以及初步感知其作用（便于后期扩展等作用）。
- java的基础特性，封装性。
题量
题量相对适中，三次作业类的数量呈递增趋势，但是都是在前一次作业的基础上进行少量修改以及扩展功能，增加类，因此只是在第一次作业时搭建框架时间较长。在基础框架也就是最大程度上做到单一职责以及类的设计合理的话，后续花费时间不会特别长.可以达到越来越熟练的程度。
难度
难度中等。这三次题目集并未涉及到复杂的算法，以及复杂类的设计，老师已经搭建出整体框架，我们只需要填充即可，会让我们对语法更加熟悉，也初步感知java这门语言的特点。
但是这三次题目集都是在完成一个整体的功能架构，设计多个类以及多个环节。在初次接触时，理解题目以及整体架构的难度较大，会出现看很久题才能够理解每个类中具体需要放置的属性，第一次题目集中只给出了简单的类间关系，我们需要先考虑每个类的具体内容再去思考他们之间的关系搭建出整体结构。写完后再去整体考虑是否满足单一职责，是否满足所给的类间关系，是否架构足够清晰合理以便于后续的扩展。会出现在写类的过程中发现已经完成的类需要增加功能，增加或者变量的情况。在实现从c到java的思维转换无法一蹰而就。
二、设计与分析
第一次题目的设计与分析
题目要求
【本次作业需求说明】
设计一个基础的航班货运配载模块。系统需要记录航班的基本信息（航班号、最大起飞重量、最大业载重量）。地勤人员可以按照货物重量从高到低向该航班添加货物（货物名称、重量）。系统需要实时计算当前已装载的总重量，并判断是否超载。
【设计要求】
类设计必须符合单一职责原则（SRP），参考类图如下所示（仅作参考，可自行加工具类）。
注意：类设计如果违背了SRP，此题不得分。
类图
各个类详细设计
- cargo 货物类：只有基础属性与方法，作为简单实体类
- loadmanifest 货物清单类：与cargo是聚合关系，除了基础的属性与方法之外有增加货物功能，与计算总重功能，符合单一职责。
- Flight 航班类：除了getter，setter方法只加了检查当前载重是否超过设定的最大载重的方法，符合单一职责
- cargosorter 货物排序工具类：作为工具类，单独拎出
源码设计与分析
Source Monitor分析结果：
分析心得
分析
由Source Monitor分析的结果可知，此次代码有以下两个问题：
一、注释不足
注释率只有3.3%，可读性差，并没有考虑后续需要优化，修改，排查问题时重新理解代码的时间成本。后续应该做到对复杂逻辑进行注释，对功能模块进行注释，以便后续修改，优化。
二、局部代码块嵌套过深（最大深度 = 5）
存在 5 层嵌套的代码块，多层嵌套会让代码的可读性差、容易出错，也不利于后续修改。可以将逻辑单独抽出变成方法，使得逻辑更加清晰，代码简洁，可读性更高。
但是在老师的类图的帮助下，实现了类的单一职责原则，类的方法与设计合理，架构清晰。
心得
通过分析不难发现，代码的可读性非常重要，关乎到后续的修改和扩展。而代码的可读性又与代码的嵌套深度，注释有关。通过这次的题目，不仅熟悉了语法知识，而且理解了java中很重要的单一职责原则，理解其在开发过程中的作用，不仅能够让代码逻辑更加清晰，也更易于扩展。明晰了整体框架的重要性，在完善代码之前应该有一个整体思路，搭建好类的大致内容，然后清楚类间关系，能够更好地更快地完成代码，以及完成高质量代码。
第二次题目的设计与分析
题目要求
在原有基础上飞机类需记录航班号，最大载重，最大业载重量，输出使用，增加货舱类实现多个方法，增加货物调度类以及输入校验类。
类图
各个类详细设计
- position类：：记录货物的具体位置。（但在实际运行时没用上，只有记录作用，可能是后续扩展需要）
- cargo类：无改动。
- CargoCompartment类：第二次作业有多个货舱，增加管理类，与货物清单相似。除了基础的属性和方法只加了add与计算现有重量的功能，不违背单一职责，后续运行，获取信息也更加方便。
- Flight类：无改动。
- loadmanifest类：基本未改变。（在写这次作业时一开始以为这个类没有用，删除后，发现计算以及获取数据，数据记录会更加麻烦，可见当同样的实体类存在多个时，可以考虑增加清单记录整体的信息，也更加符合类的设计）
- LoadDispatcher类：工具类，集成了多个对于货物的操作，排序，查找等。都是静态方法，可以通过类直接调用而不用创建对象。
- inputValidator：工具类，将多次会使用的操作抽象为一个类，减少代码冗余，更加简洁，也更易阅读。
源码设计与分析
分析心得
分析
由Source Monitor分析的结果可知，此次代码有以下四个问题：
一、注释率过低
注释率只有7.3%，只做了基础的类的说明，没有对功能进行具体说明，而且第一次注释过少，第二次作业要先将第一次代码仔细阅读，但是由于第一次作业的单一职责原则以及代码量不大，还是比较好找。第二次作业的注释过少，直接导致我第二次修改时需要频繁翻找，阅读代码，增加修改时间。应该将类的注释再写详细一点而不是只有类名，关键方法也应该增加注释。
二、代码块最大嵌套深度太高
代码块的最大嵌套深度达到7层，主要是main方法中输出时用到的嵌套太多，后续也不易阅读修改，可以提取出单独的方法。
三、命名不规范
命名时大小写并不固定，有时全是小写，有时有用驼峰命名法，调用时还是挺麻烦的。
四、main方法职责过重
main方法中有输入，输出，处理多个功能，不够简洁，也不易阅读。可以将输入，输出，单独写成方法，增加可读性。
心得
当基础类的设计大致合理时，后续增加新的功能时，可以减少修改所用的时间以及修改的量。当同样的实体类存在多个时，可以考虑增加清单记录整体的信息，也更加符合类的设计。第二次作业仍然有很严重的注释缺陷问题，需要增加写注释的意识。在命名类以及方法属性时尽量遵循规则，以便后续使用。main类中不要放太多的业务逻辑，职责过重。每个类平均七个方法，需要警惕个别类不符合单一职责原则。
第三次题目的设计与分析
题目要求
本次迭代（V3）在V2基础上的主要增量
引入旅客实体：新增旅客及行李的管理，旅客体重按标准值（75kg）自动计算。
引入核心业务算法：新增基于物理力矩的“航空器载重平衡计算”功能。
增强鲁棒性要求：在数据录入过程中，要对数据进行合法性验证，如果发现有非法输入，立即停止应用程序运行。
类图
各个类详细设计
- Luggage：只有基础的属性与方法，为新增要求而增加的实体类。
- Passenger：乘客类，实体类，只有基础的属性与方法，为新增要求而增加的实体类。
- cargo：无改动。
- position：根据新要求改动其属性，只有基本的属性与方法。
- CargoCompartment：无改动。
- Flight：无改动。
- passengerlist：由于有多个乘客，于是与货物清单一样加上了乘客名单这个类。
- loadmanifest：无改动。
- WeightBalanceCalculator：工具类，将新增的数据要求，计算要求都放在这个类中，获取多个类中的数据，减少实体类之间的耦合性，达到单一职责原则。后续需要多次调用，抽象出方法会让代码增加可读性。
- LoadDispatcher：应题目要求，将选择排序改成了冒泡排序。其他的未改变。
- inputValidator：检测是否为非法输入，简化main中每个数据都要检测合理性的逻辑。只需要调用此方法即可，用到了try，catch。
源码设计与分析
分析心得
分析
由Source Monitor分析的结果可知，此次代码有以下个问题：
一、注释率低
只考虑题目目前的需求，因为所加的功能不需要怎么改动原来的代码，所以基本没有因为这个而多耗费时间。但是可读性差的问题仍会存在，回顾代码时所需要花费的时间长，以后应该做上必要注释，使后续更好优化修改，有针对性地改动。类、方法、关键业务逻辑（如载重平衡公式、货物分配规则、输入校验逻辑）都没有说明，后续维护时，别人（甚至你自己）都很难理解代码意图。
二、圈复杂度极高
点击查看圈复杂度
> 圈复杂度 (Cyclomatic Complexity)
核心结论：圈复杂度是衡量代码判定结构复杂程度的量化指标，本质是线性独立路径数，数值越高表示代码越难理解、测试与维护。工程实践中建议将函数圈复杂度控制在10 以下，临界值11-20需关注，21+属于高风险需重构。
通俗理解：代码中的分支、循环、条件判断越多，圈复杂度越高，意味着代码逻辑越复杂，潜在缺陷风险越大。
负面影响（高圈复杂度）
1. 代码可读性差，新人难以接手。
2. 测试难度大，覆盖率难以提升。
3. 调试困难，定位问题耗时。
4. 维护成本高，修改易引发连锁反应（回归缺陷）。
5. 重构风险大，不敢轻易改动核心逻辑。
降低圈复杂度的重构方法
1. 提炼函数（Extract Method）。
2. 将复杂逻辑块提取为独立函数，遵循单一职责原则。
3. 卫语句（Guard Clauses）替代嵌套。
4. 提前返回异常 / 边界情况，减少嵌套层级。
5. 策略模式 / 多态替代条件分支。
6. 复杂条件判断可用对象多态性消除。
7. 合并重复条件：消除冗余判断。
8. 用查表法替代复杂条件：如字典映射替代 switch-case。
9. 分解条件表达式：将复杂条件拆分为多个简单条件。
10. 减少循环嵌套：最多 1-2 层循环，多层循环需重构。
经过回顾代码以及学习发现，main函数的圈复杂度高于标准设定，会增加测试难度。第一是因为使用了多个if else语句来进行不同环节输入数据有问题之后的直接结束，圈复杂度叠加。第二是main函数的功能太多，包括数据最后校验，输入输出，以及基础的添加逻辑，导致其语句以及内容太多。应该将不同部分的业务逻辑单独抽出成一个方法，main函数只进行最后的调用，分担圈复杂度，尽量降低if else语句的使用。深层原因可能是因为类太多，关系太杂不知改如何进行传递，设计，直接将添加逻辑放在main中，以及输入输出未单独提出，导致问题。
三、代码嵌套深度略高
代码最高深度为5层，略高于标准，会降低可读性，不便于测试。可以在写完后认真考虑是否有减少嵌套的可能性。
心得
在原有基础合理的情况下，在新增需求时，原有类的设计基本无改变，会减少对源代码的带动，减小测试难度。注释仍然太少，不便于代码理解以及后续迭代，修改，优化。main函数的复杂度太高，可以将功能分块抽取出方法，main函数只负责调用，会降低复杂度，降低调试难度。圈复杂度过高会导致调试难度大，代码可读性差等问题。应该在完善完类的设计之后，减小main中的功能，减少if else的使用，减少分支，降低测试难度。降低嵌套深度，增加可读性。
三、踩坑心得
1.sc.next()与sc.nextLine()的错误理解
next（）遇见空格，换行等会结束读入，且会留下换行符，nextLine（）遇到换行符才停止读入。在测试类中输入方式不同时，需要注意next（）以及nextLine（）的恰当使用，不然会造成无法正常读入，读取到换行符等情况。
2.注释占比低增加编写时间
对于三次代码质量的分析，都出现了注释量远低于标准的情况。在迭代过程中也受到其影响，例如修改，扩展原有代码困难，在修改过程中需要频繁翻阅代码。但是因为类的设计比较合理，并未在此处花费更多时间。后续写代码时应该多写注释，将重要部分的代码块的注释写出。
3.命名不规范导致编写时长增加
会导致无法快速引用正确方法，有时要回到类中去看方法的具体名称，会增加在编写过程中很多不必要的时间。
4.单一职责的好处
在编写完这三次迭代作业后，很明显地发现了单一职责的重要性与作用。当设计的类基本满足单一职责时，在后续修改，迭代的过程中，会减少对于原有类的修改，测试时间。而且代码块，类不会过于复杂，不易调试，易于找出问题。
5.在所需实体类存在多个时，考虑新增一个清单类
也就是说，当货物存在多个时，增加一个清单类，易于对信息的获取以及操作，也会简化后续流程。在我写第一个迭代时，一开始将货物的清单类减去，但后续实现业务流程时，发现过于麻烦，又增加回。于是在写第二次迭代时，加上了乘客列表类。
6.圈复杂度过高
圈复杂度过高，会使结果有多个分支情况，会增加测试难度。而且也不易于代码阅读，修改等，会有许多冗余代码或者说会在后续迭代过程中增加难度等问题。我们可以通过减少if else的使用，尽量满足类的单一职责原则，减少类的复杂度。
四、改进建议
符合单一职责原则，利于迭代
符合单一职责原则，更加利于后续的修改，迭代，也易于搭建类的整体框架，易于调试等。在第三次迭代作业中，main函数所承担的职责过多，增加了类的修改难度，增加了圈复杂度。代码不易于阅读。
使用驼峰命名法，减少编写，回顾代码的时间
在做第二第三次作业时，大小写放置位置不规范，命名混乱，很明显地带来了编写代码时间增长，调试代码时间增长等。尽量做到命名规范，会使调用方法时更加容易。
一般只创建一个scanner对象，使得能够正常获取输入
一般只创建一个scanner对象，不然会造成读取混乱。编写代码时遇到读取问题时，发现错在我的测试类中创建了scanner对象，在调用类中方法时，方法中也创造了scanner对象，导致读取混乱，读取内容缺失等问题。后续编写代码时会一直注意scanner对象的创建，只作为参数传入方法中使用。
在完成对整体类的构想，设计后再进行编写
如果并未完成对整体设计的类的构想前即开始编写，会出现第三次作业中，main中的功能太多，代码圈复杂度高，不太符合单一职责原则的情况，降低代码质量。未捋清楚类与类之间的关系，以及信息传递，导致为了便捷将部分业务流程直接加在测试类中，并不符合设计原则，后续不易改动，优化。
五、总结与建议
总结
经过这三次练习，熟悉了java的基本语法，明白了单一职责的作用，区分next（）与nextLine（），发现以后编写的代码需要增加注释的量。知道了代码质量有哪些衡量标准，知道了标准可以更好地改进，编写代码。发现在代码实际运行过程中最好只创建一个scanner对象，防止数据读取混乱。认为以后应该遵守命名规范，以便于代码更好地编写，用再频繁回顾代码。在书写代码之前应该对类的整体设计有一个大致概念，易于后续代码填充，以及单一职责原则在设计阶段的初步实现。
建议
格式输入与答案错误应该分开来显示，不然会被困在格式错误中太久，怀疑自己写的代码，增加不必要的时间花费。在明确格式错误之后，会针对格式进行调试，减少重复性工作。
浙公网安备 33010602011771号