Java航空运输货物管理系统blog总结
一、前言：
这次的航空货物运输题目的书写比上次的电梯好太多了，因为至少我做出来了，此次的航空货物运输管理系统主要是考察我们类的设计，类与类之间的关联、依赖。以及后面迭代升级后的第二次作业主要考察抽象类的设计，抽象方法的重写实现，子类与父类之间的继承关系，以及多态。这样让我们整个程序的功能变得更加完善。总的来说这两次的作业没有太大的逻辑难度，只要稍微静下心来，还是能够写出来的。ok，所以接下来我会详细的介绍一下这两道题，谈谈我做题的心路历程以及途中遇到的麻烦，以及做题后总结的心得。
二、设计与分析：
第一次航空货物管理题目：
此次题目集要求我们能根据信息给出按一定格式输出的客户信息，航班信息以及订单信息。所以此次的代码逻辑难度可以说并不复杂，主要考察我们类的设计和相应方法的实现。本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则。以及根据重量来计算运费。
主要分为 客户类用于保存客户的一些信息包括发货人收货人信息；
货物类用于保存货物的信息主要是货物的重量；
航空类用于保存航班的信息；
费率类用于计算相应的费率。
以下是我用SourceMontor的生成报表内容：
代码行数：346 行代码。语句数：206 个语句，指代码中可执行的语句数量。分支语句百分比：3.4%，表示代码中分支语句（如if、switch）占总语句的比例较低。方法调用语句数：58 个，表示代码中调用其他方法的次数。注释行百分比：0.0%，说明代码中没有任何注释行，这可能不利于代码的可读性和维护。类和接口数量：6 个，表示该文件中定义了6个类或接口。每类方法数：平均每个类有7.00个方法。每方法平均语句数：2.95 个，表示方法的平均复杂度较低。最复杂方法的行数：220 行，指代码中最长的方法长度。
主要问题：
代码逻辑太过于拘泥，对于现实生活中复杂的情况是不能很好的去解决问题的，而且对于多个货物的问题没有得到解决。
解决方案：
使用继承的方法，应用抽象类和抽象方法来解决多种情况的发生。
所以第二次作业来了
第二次的航空管理类在第一次的基础上增加了客户类型，货物数量，货物类型，所以根据不用的货物的类型衍生出了不同的费率；所以我们将费率类定义成父类，更具不同的类型写出不同的子类。继承父类，以此来解决这个问题。
这是我的第二次类图关系：
Customer（客户）功能：存储客户信息，如类型、ID、姓名、电话和地址。
Cargo（货物）功能：描述货物的属性，包括尺寸（宽、长、高）、重量和类型。
Flight（航班）功能：描述航班信息，包括航班号、出发地、目的地、日期和最大载重量。
Order（订单）功能：存储订单信息，包括订单号、日期、发件人和收件人信息、航班信息、货物列表和客户对象。
Rate（费率）存储不同类型的货运费率（普通、危险品、加急）。
class Rate {
private double[] normalRates = {35, 30, 25, 15};
private double[] dangerousRates = {80, 50, 30, 20};
private double[] expediteRates = {60, 50, 40, 30};
// 根据单个货物的计费重量获取费率
public double getRateByWeightAndType(double weight, String type) {
double[] rates;
if ("Normal".equals(type)) {
rates = normalRates;
} else if ("Dangerous".equals(type)) {
rates = dangerousRates;
} else {
rates = expediteRates;
}
if (weight < 20) {
return rates[0];
} else if (weight >= 20 && weight < 50) {
return rates[1];
} else if (weight >= 50 && weight < 100) {
return rates[2];
} else {
return rates[3];
}
}
}以下是我用SourceMontor的生成报表内容：
396 行代码。语句数：249 个语句，指代码中可执行的语句数量。分支语句百分比：6.4%，表示代码中分支语句（如if、switch）占总语句的比例。方法调用语句数：78 个，表示代码中调用其他方法的次数。注释行百分比：3.3%，说明代码中有少量注释行，但仍然偏低。类和接口数量：1 个，表示该文件中定义了1个类或接口。每类方法数：平均每个类有46.00个方法，这表明类的方法数量较多，可能存在过度设计或单一类承担过多职责。每方法平均语句数：5.22 个，表示方法的平均复杂度适中。最复杂方法的行数：183 行，指代码中最长的方法长度。最复杂方法的名称：printOrderInfo(), calculateTotalFreight()，表示代码中最复杂的方法名。主要问题：
代码的逻辑太过于冗杂，对于抽象类的运用太过拘泥，还有就是支付类的功能太过于简单，实际用起来并不方便。
解决方案：
将支付类设计成抽象类，定义抽象方法在子类中重写。
三、踩坑心得：
最花费我时间的就是我们那个输出格式，我搞一半天都不知道怎么输出，最终还是同学告诉我怎么改才改对的。
然后就是没注意到那个客户类型，我以为就是单纯的客户不一样，结果导致我没有看到还有新的计算费率的要求，导致我最后一直不知道我错在哪儿，直到我最后再去读了一遍题才发现，我的计算方法出问题了。
还有问题就是在于每次迭代升级的过程中，不能全部推倒重来，而是要在原有代码的基础与逻辑下继续完善和润色代码，就好比是建造一个房子，每次对房子的改进都是在原有的基础上添砖加瓦，没有把整个房子推到重来的方式。
四、改进建议：
怎么说呢，对于我自己写的代码，我觉得就是一坨又丑又长的粑粑，代码的可读性不够高，逻辑复杂但是又没有深度。但是你说他差，但是它又能正确的运行出题目要求的结果，这导致我都不知道该从何修改我的代码。所以我自己给自己提出以下几点改进的建议。
浙公网安备 33010602011771号