航空货运管理系统总结

一、前言：

• 相比上一次的题目的电梯题，这一次的题目相对简单一点，但是这两次题目对于面向对象程序设计原则的考量要多于上一次题目。
• 对于我来说，这两次的题量适中
• 通过这两次的题目，我对于面向对象设计原则更加熟悉，对它的理解也更加深刻了。了解了不同的设计原则对于程序设计有什么帮助，和如何运用这些设计原则。

 

二、设计与分析：

 

第一次题目

类图：

 

SourceMonitor生成报表：

 

分析：

（一）代码规模：

• 行数：代码文件有 401 行，有 293 条可执行语句

（二）结构相关：

• 类和接口数量：包含 5 个类或接口，说明代码在结构上进行了一定程度的封装和抽象，利于模块化管理。
• 方法调用语句：有 76 条方法调用语句 ，反映出代码通过方法调用来组织功能，具备较好的结构化。

（三）分支相关：

• 分支语句比例：分支语句占比低，代码执行路径相对简单直接，可能逻辑判断场景较少，或者逻辑设计上较为简洁。

（四）复杂度相关：

• 从雷达图中可大致判断各维度指标的均衡性。
• 柱状图体现语句数量与深度关系。可以看出深度为 1 和 2 的语句数量较多，说明大部分代码逻辑层次较浅，整体结构相对扁平，复杂嵌套少 

 

第二次题目

类图：

 

SourceMonitor生成报表：

 

分析：

（一）代码规模：

• 代码文件有 613 行，，可执行语句有 403 条 。

（二）结构相关：

• 类和接口数量：拥有 13 个类或接口，表明代码在结构设计上进行了高度的模块化和抽象化，有利于代码的维护、复用和扩展。
• 方法调用语句：存在 112 条方法调用语句，体现出代码通过方法间的调用组织功能逻辑，具备良好的结构化编程特征。

（三）分支相关：

• 分支语句比例：分支语句占比不高，说明代码整体执行路径相对集中，没有过于复杂的条件判断逻辑。

（四）复杂度相关：

• 深度为 1 和 2 的语句数量较多，表明大部分代码逻辑层次较浅，整体结构相对扁平，复杂的嵌套逻辑较少 。

 

心得：

 面对这两份代码，从规模上便有直观感受。一份 401 行，另一份 613 行。行数差异背后，是功能复杂度与实现逻辑的不同。代码结构方面，类和接口数量的差异（5 个对比 13 个）让我明白合理的模块化能极大提升代码的可维护性与扩展性。更多的类和接口意味着更精细的功能划分，就像搭积木，每个模块各司其职，组合起来完成复杂任务。

 分支上，两份代码分支语句占比都不高，执行路径相对简单。这在一定程度上让代码逻辑清晰易懂，但也反映出可能在处理复杂业务场景时不够灵活。方法调用语句较多，体现出结构化编程的优势，将大问题拆解为小方法，降低耦合度，增强了代码的可读性和复用性。

 注释严重缺失是两份代码的通病。写代码注释是一个程序员的基本习惯，我以后一定要养成写注释的习惯。

 在复杂度分析环节，雷达图和柱状图从不同角度提供信息。柱状图展示语句深度分布，让我看到大部分代码逻辑层次浅，结构扁平。虽整体利于理解，但也提醒我在复杂项目中要平衡扁平结构与深度逻辑。

 此次代码分析经历，是对课堂知识的实践检验。它让我明白高质量代码不仅要实现功能，更要在结构设计、注释规范、复杂度控制等方面下功夫。未来写代码时，我会牢记这些要点，努力编写出简洁、清晰、易维护的代码。

 

 

三、踩坑心得：

 这两次的题目整体难度相比上次的题目要简单，因此我做起来还是比较顺利的。但是在完成的过程也遇到了一些困难。

 在做第一次题目的时候，我对于该怎样划分类的职责犯了难。因为题目没有给类图，所以我自己只划分了Order，Customer，Good，Flight四个类。现在看来，和第二次较为完善的版本相比，我才知道第一次的类的设计有很多不足。第二次题目比第一次多加了OrderItems和Payment类，Payment之下还继承了Wechat、AliPay，Cash三个子类。除此之外，第二次题目题干也增加了货物类型和顾客类型。因此在Good下需要添加三个子类，Customer类同样需要添加三个子类。经过第二次题目的修改，各个类的职责更加单一，可扩展性也更强了，比如Payment可以添加子类来扩展，而不用修改其他地方的代码。第一次题目的Order类里包含了很多东西，有OrderItems还有Payment，这就使得Order的职责不够单一。第二次也将OrderItems从Order中分离出来了，还将一些相关的属性分离到OrderItems类中。

 此外，我在输入信息的地方卡了一会儿。在输入一个int或者double类型的数后，如果要继续输入一个字符串，会将换行读入导致没有读入后面真正想要读入的东西，因此造成程序错误。如果在一个非字符串型的输入后面有字符串的输入，需要在此后面加上一个next（）消耗掉多余的换行符。

 经过这两次的题目遇到的问题，我收回颇丰。首先也是最重要的一点是我对于类的设计有了基本的了解，对于程序设计原则有了更深刻的理解。其次，我对于Java的一些语法知识也有了了解，为今后我的编程打好基础。

 

四、改进建议：

1. 代码结构与设计方面

• 抽象类和接口的使用：可以进一步抽象一些公共的行为到接口中，例如 Payment 类可以实现一个 Payable 接口，将 getName 方法放到接口中，这样可以提高代码的可扩展性。
• 单一职责原则：部分类承担了过多的职责，例如 Main 类既负责输入处理，又负责订单的创建和显示。可以将输入处理和订单创建逻辑提取到单独的类中，提高代码的可维护性。

2. 输入验证方面

• 输入格式验证：在 Main 类中，没有对用户输入的格式进行验证，例如日期格式、电话号码格式等。可以添加输入验证逻辑，避免因用户输入错误导致程序崩溃。
• 输入范围验证：对于一些有范围限制的输入，如货物的重量、航班的最大载重等，应该进行范围验证，确保输入的值在合理范围内。

3. 代码复用方面

• 常量提取：将一些常量提取到单独的类或接口中，避免在代码中硬编码，提高代码的可维护性。例如，将计费重量的分段阈值和费率提取到常量类中。
• 方法复用：可以将一些重复的代码提取到公共方法中，例如计算货物费用的逻辑可以提取到一个公共方法中。

4. 性能方面

• 在 OrderItems 类中，calculateTotalWeight 方法每次调用都会遍历列表计算总重量。可以考虑在添加货物时实时更新总重量，避免重复计算。

通过以上改进，可以提高代码的可维护性、可扩展性和健壮性。

 

五、总结：

在 Java 面向对象编程的学习过程中，最近完成的两次题目集让我收获颇丰，同时也引发了许多思考。在此，我将对这两次题目进行综合性总结，分享自己的学习成果，探讨需要进一步学习的方向，并对课程相关方面提出改进建议。​

一、学习收获​

（一）深化面向对象设计原则理解​

通过两次练习，我深化了对面向对象设计原则的理解。例如，在第二次题目中，将 Payment 类进行细分，使其职责单一，并且能够方便地通过添加子类扩展功能，这正是单一职责原则和开闭原则的体现。明白了不同设计原则在程序设计中的作用，以及如何将它们运用到实际代码中，极大地提升了我的代码设计能力。​

（二）提升 Java 语法与编程能力​

在解决题目的过程中，对 Java 的一些语法知识有了更深入的理解和运用。比如在处理输入时，掌握了如何解决因输入类型转换导致的换行符读取问题，学会了在合适的场景下使用抽象类和接口。同时，通过不断地编写、调试代码，编程能力也得到了锻炼，对程序的逻辑把控更加熟练。

二、将来的学习方向

（一）代码规范

两次题目中代码注释严重缺失，暴露出我在代码规范方面的不足。规范的代码注释能够极大地提高代码的可读性和可维护性，我需要学习并养成良好的代码编写习惯。

（二）面向对象程序设计原则

通过这两次的题目，我深刻认识到了面向对象设计原则为程序设计到来的好处，我也知道自己在设计原则的运用并不好。因此，我需要学习并运用好面向对象设计原则，提升自己的面向对象编程能力。

三、对课程的建议

该课程着重培养我们的面向对象的思想，通过这门课的学习，我的面向对对象编程能力确实得到了明显的提升。对于面向对象程序设计的学习，我对设计原则的认识还是不够。在平时的练习中，我们的题目往往都是对多种设计原则的综合考量，因此我有时无法区分每个设计原则的作用，这也导致编程时不确定自己的设计是否符合面向对象设计原则。

所以，我希望老师们将来可以单独讲解或者出一些设计原则，让我们对于每一个设计原则有更加深刻的理解。同时，我也希望老师可以多多扩展一些除了面向对象设计原则的知识，丰富我们的知识面。

 

通过对这两次 Java 面向对象题目的总结，我清晰地看到自己的成长与不足。在未来的学习中，我将针对薄弱环节加强学习和实践，同时也希望课程在各方面能够不断优化，帮助我们更好地掌握 Java 面向对象编程技术，为今后的学习和工作打下坚实的基础。