航空运货系统

1.发布题目集8~9的总结性Blog，内容要求如下：

（1）前言：总结两次题目集的知识点、题量、难度等情况

（2）设计与分析：重点分别对两次题目集中的“航空货运管理系统”题目的提交源码进行分析，可参考SourceMontor的生成报表内容以及PowerDesigner的相应类图，要有相应的解释和心得（做到有图有真相），本次Blog必须分析题目集8~9的航空货运管理系统问题
在上次经过电梯的大作业的折磨之后,我努力学习,写大作业,终于写出来了

第一次看到这个题目,我以为又是要和写电梯一样,都是些逻辑思考很久,不会思考了一会,感觉就是一些小问题,只是题目很长,花了很长时间才理解,在输入和输出方面花了挺多时间的
代码分析

代码规模相关指标
行数（Lines）：332 行，代码量适中，但行数不能完全代表代码复杂度，还需结合其他指标分析。
语句数（Statements）：227 条，平均每行语句数约为 0.68 条 ，说明代码不是特别紧凑。语句类型（如赋值、条件、循环语句等）的分布会影响代码逻辑复杂度和执行效率。
代码结构与逻辑指标
分支语句百分比（Percent Branch Statements）：15.0% ，意味着代码中有一定比例的条件判断逻辑，如 if - else、switch 语句等。较多的分支会使代码逻辑走向增多，增加测试和维护难度，需关注是否存在复杂的嵌套分支结构。
方法调用语句数（Method Call Statements）：67 条，说明代码中方法间调用频繁。合理的方法调用可提高代码复用性，但要注意避免过度耦合，以及确保方法调用的合理性和准确性。
代码规范指标
含注释的行百分比（Percent Lines with Comments）：仅 3.3% ，注释严重不足。良好的注释能极大提升代码可读性，方便自己后续回顾和他人理解代码逻辑，应按规范补充类注释、方法注释和关键逻辑注释。

在写第二次迭代的大作业的时候,我又看到了继承与多态,我还是不会,改多了第一次的代码,甚至改出了问题,到最后也没找出问题所在,没有获取分数
类与方法相关指标
类和接口数量（Classes and Interfaces）：1 个 ，类数量过少，可能导致单个类承担过多功能，不符合面向对象设计中高内聚、低耦合原则。应考虑按功能将代码拆分为多个类。
每个类的方法数（Methods per Class）：22.00 个 ，方法数量较多，可能造成类的职责不够单一，增加代码理解和维护难度。建议对方法进行合理分组和重构，使每个类的功能更明确。
每个方法的平均语句数（Average Statements per Method）：9.82 条，平均长度尚可，但需关注方法内部逻辑是否复杂，是否存在可提取为独立方法的代码片段。
复杂度相关指标
最复杂方法的行数（Line Number of Most Complex Method）：249 行，是 Main.main() 方法 ，该方法行数多且复杂度高。复杂度过高的方法不利于理解、调试和维护，可通过功能拆分来降低复杂度。
最大复杂度（Maximum Complexity）：9 ，表明代码中存在较复杂的逻辑结构，可能涉及大量条件判断、循环嵌套等。
最深块的行号（Line Number of Deepest Block）：91 行，最大块深度（Maximum Block Depth） 为 4 ，说明代码中存在多层嵌套结构（如嵌套的 if、for 等语句），这会降低代码可读性和可维护性，修改时容易出错，可考虑优化嵌套逻辑。
平均块深度（Average Block Depth）：1.49 ，平均复杂度（Average Complexity）：9.00 ，反映整体代码在结构和逻辑上有一定复杂度，需要在后续开发中注重代码重构和优化。
经过ai的分析,和我自己的理解,我觉得我需要将类的职责再细一点划分,类的数目太少了,一个类承担的职责过于多了,这样会导致不符合面向对象程序设计,main里面的圈复杂度也太高了

看到题目的时候,我需要改变类的设计,于是我该来改去,到最后竟然改出了问题不能正常输出,所以没有得到分数

代码规模相关指标
行数（Lines）：349 行，代码量不算少，但行数多并不直接等同于代码复杂，还需结合其他指标综合判断。
语句数（Statements）：165 条，平均每行约 0.47 条语句 ，代码密度相对较低。语句类型（如赋值语句、控制流语句等）的具体分布对代码的逻辑复杂度和执行效率有重要影响。
代码结构与逻辑指标
分支语句百分比（Percent Branch Statements）：3.6% ，说明代码中条件判断逻辑占比较少，代码逻辑相对较为线性，这在一定程度上有利于代码的理解和维护，但也可能意味着功能的丰富度不够。
方法调用语句数（Method Call Statements）：16 条，方法调用次数较少，代码中方法间的交互相对不频繁。如果方法调用合理，可提高代码的复用性；但调用过少可能表示代码的模块化程度不高。
代码规范指标
含注释的行百分比（Percent Lines with Comments）：2.9% ，注释比例极低，这会严重影响代码的可读性和可维护性。无论是自己后续回顾代码，还是团队成员接手维护，缺乏注释都将使理解代码逻辑变得困难，应按规范补充必要注释。
类与方法相关指标
类和接口数量（Classes and Interfaces）：2 个 ，相较于单个类的情况，有一定的结构划分，但数量仍较少，可能存在单个类承担过多功能的问题，不符合高内聚、低耦合的面向对象设计原则。
每个类的方法数（Methods per Class）：42.00 个 ，每个类拥有的方法数量极多，这可能导致类的职责不清晰，代码的可维护性变差。应考虑对方法进行合理拆分和归类，使每个类的功能更加单一明确。
每个方法的平均语句数（Average Statements per Method）：1.87 条，平均语句数较少，说明方法相对短小。短小的方法在一定程度上便于理解和维护，但也要关注方法是否过于碎片化，导致整体代码结构不够清晰。
最复杂方法的行数（Line Number of Most Complex Method）：{undefined} ，最复杂方法名称（Name of Most Complex Method）：{no methods} ，最大复杂度（Maximum Complexity）：0 ，表明代码中不存在复杂度特别高的方法，从复杂度角度看代码相对简单，但也可能反映出代码功能不够丰富或者复杂度分析存在异常。
复杂度相关指标
最深块的行号（Line Number of Deepest Block）：81 行，最大块深度（Maximum Block Depth）：2 ，平均块深度（Average Block Depth）：0.59 ，平均复杂度（Average Complexity）：0.00 ，这些指标说明代码中的嵌套结构较少，整体复杂度较低，代码逻辑相对简单直接，在维护和理解上难度较小，但也可能意味着代码在处理复杂业务逻辑方面能力不足。

通过ai的解释,类中方法数量过多会使职责不清晰，方法平均语句数可辅助判断方法长短。方法短小有易维护优势，但也不能过度碎片化；而方法数量和复杂度不合理时，需进行拆分重构。
心得:
经历第一次大作业的失败后，这次面对作业，心态和行动都截然不同。不再慌乱与拖延，而是沉着地拆解题目任务，规划好每一步，作业布置就立即着手，每日稳步推进。

碰到难题，不再消极等待，主动从书本找知识、上网搜资料，虚心向同学老师请教。在处理电梯调度程序请求逻辑时，借助多方经验攻克难关，知识掌握更牢，还积累实战技巧。

代码编写严格遵循改进思路。拆分职责模糊类，让功能更聚焦；在关键处添加丰富注释，提升可读性；以高效数据结构替换复杂嵌套，优化算法效率。

不过，仍有进步空间。类设计和调用关系自主设计能力欠佳，多借鉴现有模式，灵活性和创新性不足。代码性能优化也待加强，资源管理释放等方面有提升余地。

后续计划通过大量项目练习，强化类设计相关能力，对比优秀案例找差距。深入钻研性能优化知识，合理管理资源、提升算法效率，持续提升编程水平。

总结:通过两次作业的实践与反思，我在编程思维、代码设计和问题解决能力上有了显著转变，也深刻认识到自身的不足与改进方向。