航空货运管理系统总结性blog

航空货运管理系统总结性blog

前言

这一阶段的pta迭代性作业又结束了，按照惯例，写一份总结性blog。重点分析两次题目集的最后一题——航空货运管理系统。

在题目集08中，对于航空货运管理系统主要是进行类设计。涉及到的知识点主要有（按大类）：

1. 面向对象编程。其中又细化为：
2. 类的定义和封装
3. 构造方法和构造方法的重载
4. 访问修饰符（private、public等）
5. 数组列表ArrayList，主要用来存储货物的订单信息。

而在题目集09中，包含了以上知识点，但同时还新增了部分知识点，包括但不限于：

1. 继承和多态，方法重写
2. 可以使用接口来计算费率，但不是必须。

总而言之，此阶段的编程练习还是涉及到java语言中最核心的部分——面向对象。还有就是面向对象的七大设计原则，其中最能体现的就是单一职责原则和开闭原则。

接下来是难度分析，相比于上一阶段的单部电梯调度程序，我个人认为此阶段的航空货运管理系统要相对容易一些，可能是在逻辑上要比电梯程序简单，按照作业说明写就能写出来。又或者是我个人对电梯程序中的队列不是很懂而导致的，反正这次的航空货运管理系统没有涉及太深的逻辑和算法。

而这一阶段的两次题目集的题量和以往一样不算多，都是三道题目，题不在多而在于精，前两道题也算容易，这样可以留有更多的时间给最后一题。

设计与分析

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

某航空公司“航空货运管理系统”中的空运费的计算涉及多个因素，通常包括货物重量/体积、运输距离、附加费用、货物类型、客户类型以及市场供需等。空运以实际重量（Gross Weight）和体积重量（Volume Weight）中的较高者作为计费重量。
计算公式：
体积重量（kg） = 货物体积（长×宽×高，单位：厘米）÷ 6000
本次题目模拟某客户到该航空公司办理一次货运业务的过程：航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班日期，航班最大载重量）
客户填写货运订单并进行支付，需要提供如下信息：
 客户信息（姓名，电话号码等）
 货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
 运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选航班号，订单日期）
 支付方式（支付宝支付、微信支付）
一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费。

可以从题干看出题目不是非常复杂。

下图为该题目我画的类图，可以看到使用了定义了CalculatorRate接口来计算费率，在我看来订单是有计算费率的能力的，故考虑使用接口。然后就是题目要求的一些普通类，比如货物Cargo、订单Order、客户Customer、航班Flight等等，枚举类型enum属于可要可不要，可以使用字符串替代。

通过类图可以看到，实现了类的单一职责原则，保证了各个类所要做的工作量都控制在一定程度，便于代码管理以及可读。

接下来是SourceMonitor的分析。

Cargo类：

可以发现Cargo类的注释占比过高，存在过度注释的问题。

Customer类：

Customer类的注释占比又比较低了，用idea的自动生成get和set函数，其实有很多的get/set函数都没用上，这一点可以在日后的编程中解决。

Flight类：

Order类：

TransformInformation类：

Main类：

对于主函数Main来说，由SourceMonitor分析来看，方法的复杂度过高，调用方法的次数也过多了，注释覆盖率也不高，这些问题在日后的编程中都要尤其注意。

还有一个大问题是，从我的源码来看，我的大部分注释都是把题目的要求和一些数据复制到idea中去并注释掉，然后对着来写，这样不用来回切换窗口。所以其实去掉这些无用的注释，真正的与题目有关的注释其实是少之又少的，注释不足的问题在目前来看是小事，但要是放到以后的编程开发中，需要进行团队合作时，就是一个巨大的问题了。所以在日后的编程中，要加强写一些有关题目本身的注释。

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

第二次航空货运管理系统作业在第一次作业类设计的基础上增加了继承和多态，其实我在第一次作业中就使用了接口，也就自然而然的使用了多态，所以两次作业对比来看，我其实没有做多少迭代。

然后第二次作业还多了一些内容，比如第一次作业只有普通货物，第二次作业在这个基础上新增了加急货物和危险货物，不同的货物计算费率的方式不同，所以一样可以使用接口来进行费率的计算。还有一点新增的就是本次作业在基础费用的计算上新增了一个折扣率，其中，折扣率是指不同的用户类型针对每个订单的运费可以享受相应的折扣， 在本题中，用户分为个人用户和集团用户，其中个人用户可享受订单运费的9 折优惠，集团用户可享受订单运费的8折优惠。

类图如下：

与第一次作业类似，在此就不做过多的冗余分析。

SourceMonitor分析如下：

Cargo类：

CargoInformation类：

客户类Client：

航班类FLight：

订单类Order：

Main类：

在这里主要分析一下Main类的代码。由SourceMonitor分析来看，有着和第一次作业一样的问题，方法平均复杂度高、代码注释率低，还有一点main方法中的语句过多，可能会违反单一职责原则。这通常是很致命的，要是出错了将会带来很麻烦的后果。同时还显示深度2代码占比很高，这表明嵌套语句过多，这确实没毛病。在源码中使用了大量的if-else嵌套，还时不时的在if-else中嵌套for循环。

采坑心得

在这两次题目集中，踩得坑也是有一些的。

1. 输出格式的问题，由输出格式样例来看，除了“-”的个数外，当然这个是可以复制的，通常不用自己去数，最大的坑就是“ ”了，我就一个一个的数敲了几下空格，直到提交以后报格式错误的错，我还纳闷哪里有问题，直到去测试了一下，发现根本不是空格，而是制表符。虽然这个不算大坑，可以通过测试样例来发现到底是制表符还是空格，但也还是算一个坑吧。还有一个格式问题就是纯粹的个人粗心，当订单中货物重量超过了航班的剩余重量时要求输出一句话The flight with flight number:航班号 has exceeded its load

capacity and cannot carry the order.然后结束程序，我当时想也没想就直接把这句话复制过去了，然后直接System.out.println输出，结果也是报一个大大的答案错误，我也是找了很久很久，一开始我认为是我程序中哪里出现了逻辑错误，直到我在idea中花了很多时间打断点单步调试发现所有数据和输出结果都没错后，我才发现这里的航班号竟然是真的“航班号”。所以还是要细致。

2.第二个问题就是支付方式的问题，在第一次作业中好像是只能使用微信支付，并没有要求输入支付方式，然后根据不同的输入来使用不同的支付方式，于是在第一次作业中支付方式这个坎我卡了很久，在第二次作业中就没有这个问题了。

改进建议

对于改进建议这一块，还是在设计与分析中提到的问题，“方法平均复杂度高、代码注释率低，还有一点main方法中的语句过多，可能会违反单一职责原则。这通常是很致命的，要是出错了将会带来很麻烦的后果。同时还显示深度2代码占比很高，这表明嵌套语句过多，这确实没毛病。在源码中使用了大量的if-else嵌套，还时不时的在if-else中嵌套for循环。”，这些都是我的源码中所体现出来的问题，在日后的编程中需要改进的地方。

还有就是要提高自己的对代码的敏感度，就和做线代题目一样，只有对数字敏感了才能快速解题。编程也是一样，只有对代码敏感了，才能在出现错误的时候快速的找到自己到底是哪里错了，要是是逻辑错误的话，哪里由逻辑问题，如果不是逻辑错误的话，又是哪里和输出样例不同，这些都要依赖对代码的敏感度。

总结

通过这两次的迭代性编程，我对面向对象程序设计的理解加深了，最显著的就是类的封装、继承和多态这三大核心，当然还有接口的定义和使用。还有面向对象七大基本原则的体现，类的单一职责原则和开闭原则、里氏替换等等。