第二次Blog作业

航空货运管理系统总结

一、前言

知识点：

继承与多态、抽象类与抽象方法、设计原则

题量：

这两次题目集题目数量都为三道，题量并不算多

难度：

相比较于上次的题目，这次的题目比较简单，但对类的设计和面向对象设计原则的要求要比上次严格

二、设计与分析

第一次航空货运管理系统分析

题目说明

本次题目模拟某客户到该航空公司办理一次货运业务的过程：

航空公司提供如下信息：

航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班

日期，航班最大载重量）

客户填写货运订单并进行支付，需要提供如下信息：

客户信息（姓名，电话号码等）

货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）

运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选

航班号，订单日期）

支付方式（支付宝支付、微信支付）

注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独

计费。

程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信

息报表及货物明细报表。

1.类图

2.SourceMonitor生成报表：

分析：

Lines：代码行数，共 445 行。

Statements：语句数量，有 269 条语句。

Percent Branch Statements：分支语句百分比，占 3.3%。

Method Call Statements：方法调用语句数量，共 60 条。

Percent Lines with Comments：含注释的代码行百分比，仅 0.9% ，说明代码中注释较少。

Classes and Interfaces：类和接口数量，共 5 个。

Methods per Class：每个类平均方法数，为 14.40 。

Average Statements per Method：每个方法平均语句数，是 2.24 。

Line Number of Most Complex Method：最复杂方法所在行号，在 38 行。

Name of Most Complex Method：最复杂方法名，是Goods.calculateRate() 。

Maximum Complexity：最大复杂度，为 5。

Line Number of Deepest Block：最深代码块所在行号，在 40 行。

Maximum Block Depth：最大代码块深度，为 3。

Average Block Depth：平均代码块深度，1.68 。

Average Complexity：平均复杂度，1.08 。

总结：

注释太少（仅 0.9%）：后续维护困难

方法复杂度不均：个别方法复杂度达 5，需拆分简化

代码嵌套较深：最大深度 3，可能影响可读性

分支语句过少（仅 3.3%）：可能存在逻辑覆盖不全

第二次航空货运管理系统分析

题目说明

本次题目模拟某客户到该航空公司办理一次货运业务的过程：

航空公司提供如下信息：

航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载

重量）

2

客户填写货运订单并进行支付，需要提供如下信息：

客户信息（姓名，电话号码等）

货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）

运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选

航班号，订单日期）

支付方式（支付宝支付、微信支付、现金支付）

注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独

计费。

程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信

息报表及货物明细报表。

1.类图

2.SourceMonitor生成报表：

分析：

Lines：共 583 行。

Statements：有 168 条语句。

Percent Branch Statements：分支语句占 7.7% ，比例正常，说明有一定逻辑判断结构。

Method Call Statements：15 条方法调用语句，数量较少。

Percent Lines with Comments：注释行占比 0.0% ，完全没有注释，会给代码理解和维护带来极大困难。

Classes and Interfaces：有 11 个类和接口，数量较多。

Methods per Class：平均每个类 3.91 个方法，分布较为均匀。

Average Statements per Method：每个方法平均 2.00 条语句，方法相对简单。

Line Number of Most Complex Method：最复杂方法在 13 行。

Name of Most Complex Method：是NormalGoods.calculateRate() 。

Maximum Complexity：最大复杂度为 5 ，存在一定复杂度的方法。

Line Number of Deepest Block：最深代码块在 15 行。

Maximum Block Depth：最大代码块深度 3 ，存在一定嵌套。

Average Block Depth：平均代码块深度 1.51 ，整体嵌套不算深。

Average Complexity：平均复杂度 1.30 ，整体复杂度不算高。

总结：

1.注释缺失：注释行占比为 0.0% ，代码无注释，后续理解和维护难度极大。

2.方法调用少：仅有 15 条方法调用语句，可能意味着代码模块化程度欠佳，功能实现上可能存在大量代码集中在单个方法或类内，不利于代码复用和扩展。

3.复杂方法孤立：NormalGoods.calculateRate()方法复杂度达 5 ，与平均复杂度 1.30 差距明显，该方法内部逻辑可能较为复杂、耦合度高，修改时容易引入新问题。

三、踩坑心得

在做第一次题目的时候没有仔细看清题目的要求，没发现要输出的是计费重量而不是物体的实际重量，也没注意到题目要求的输出格式是用\t而不是用空格，导致提交的时候提醒部分错误。在做第二次题目的时候没注意到输入的支付方式是英文的而输出支付方式是中文的。在做两次题目的时候，刚开始均没有认真地设计过类和考虑类和类之间的关系，最后做到一半的时候发现越来越难做从而不得不放弃，重新开始设计类。

四、改进建议

1. 要在写代码的时候多写注释，提高代码的可理解和可维护性。
2. 要认真的设计好类与类之间的关系。
3. 写的代码要符合面向对象六大设计原则。
4. 类设计与职责单一性，部分类不符合这一点，例如Order类负责订单相关操作，既计算总价、总重量，又处理订单相关信息管理。可考虑将计算逻辑提取到单独的服务类中，使Order类专注于订单信息存储和管理。
5. 优化输入处理：Main类中输入逻辑较冗长且重复，可封装成独立方法，提高代码复用性。

五、总结

（一）、学习收获：

1.加深了对面向对象设计原则的理解和运用。

2.加深了对继承和多态的理解和掌握。

3.学会了使用抽象类和抽象方法。

4.知道了要设计好类和类与类之间的关系要把握准确。

（二）、对课程的建议

可以多出一些可以加深我们对面向对象设计原则的理解的题目，多出一些关于类设计和类与类之间的关系的题，加强面向对象编程能力。