第二次Blog作业

第二次Blog作业
一． 前言
在8，9两次题目集中，有3+3共6道题，题目量依旧不大，但难度相较前几次题目集略有提高，尤其是代码复杂度，有较大提升。每个题目集的难度以递增呈现，前两题为以前题目集中的题目的迭代，要求用继承与多态完成，第三题则是这两次题目集中最重要的部分，航空货运订单管理。第二次题目集中对第一次题目集中的航空货运管理进行迭代，要求实现更多功能，全面考察了 Java 基础语法、面向对象编程思想以及数据处理能力。巧妙地将编程与实际问题进行结合，本次作业使我不仅巩固了课堂所学知识，还深刻体会到了理论与实践相结合的重要性，同时也对面向对象设计原则有了更为深入的理解和实际运用经验。
二． 设计与总结
题目集8：
航空货运管理系统整体设计思路
航空货运管理系统的核心是处理客户订单和货物运输，需要根据航班载重限制和货物特性进行合理调度。设计应遵循面向对象编程思想，将不同功能封装到不同类中，提高代码的可维护性和可扩展性。主要涉及客户类、货物类、航班类和订单类，同时要处理好输入输出以及订单的处理逻辑。
各部分详细设计
对于航空货运管理系统，共设计五个类：Customer（客户类），Cargo（货物类），Flight（航班类），Order（订单类），Main（主类）。

航空货运管理系统类设计
Customer（客户类）
属性设计：

customerId：客户编号
name：客户姓名
phone：客户电话
address：客户地址
cargoList：客户的货物列表

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
addCargo (Cargo cargo)：添加货物到列表
getTotalCargoWeight ()：计算客户所有货物的总重量
Cargo（货物类）
属性设计：

cargoId：货物编号
name：货物名称
width：货物宽度
length：货物长度
height：货物高度
weight：货物重量

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
calculateVolumeWeight ()：计算体积重量（长 × 宽 × 高 / 6000）
getChargeableWeight ()：获取计费重量（实际重量和体积重量的较大值）
getRate ()：根据计费重量确定费率
calculateFreight ()：计算货物运费
Flight（航班类）
属性设计：

flightNumber：航班号
departureAirport：起飞机场
arrivalAirport：降落机场
date：航班日期
maxWeight：航班最大载重量
currentWeight：航班当前载重

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
getRemainingWeight ()：获取剩余载重量
canCarry (double weight)：判断航班是否能承载指定重量
addWeight (double weight)：增加航班载重
isOverloaded ()：检查航班是否超载
Order（订单类）
属性设计：

orderId：订单编号
orderDate：订单日期
senderAddress：发件人地址
senderName：发件人姓名
senderPhone：发件人电话
recipientAddress：收件人地址
recipientName：收件人姓名
recipientPhone：收件人电话
customer：关联的客户
flight：关联的航班

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
calculateTotalWeight ()：计算订单总重量
calculateTotalFreight ()：计算订单总运费
calculatePaymentAmount ()：计算微信支付金额（含手续费）
validateOrder ()：验证订单信息完整性
Main（主类）
功能：读取用户输入，解析输入并创建对象，处理订单逻辑，输出结果。

数据结构选择：

对于货物列表，使用 ArrayList 存储，方便动态添加货物。
对于订单处理，按输入顺序处理，无需特殊数据结构。
Souce Monitor分析结果：

行数（Lines）：333 行，表明代码文本量相对较多，代码规模较大。
语句数（Statements）：133 条，体现了代码中执行单元的数量，反映了代码实际可执行操作的多少 。
分支语句占比（Percent Branch Statements）：6.0% ，说明代码中如 if - else、switch 等分支逻辑的占比较低，代码逻辑的分支情况相对不复杂。
方法调用语句数（Method Call Statements）：50 次，反映了方法之间相互调用的频繁程度，调用次数不算高。
注释行占比（Percent Lines with Comments）：5.1% ，注释占比较少，可能会对代码后期的理解和维护造成一定困难。
类和接口数量（Classes and Interfaces）：0 个 ，说明代码中未定义类和接口，代码结构可能是面向过程风格，结构相对简单。
每个类的方法数（Methods per Class）：0.00 ，因为没有类，所以该值为 0 。
每个方法平均语句数（Average Statements per Method）：6.78 条 ，如果从假设存在方法的角度看，单个方法内语句数量不算多。
最复杂方法行号（Line Number of Most Complex Method）：{undefined} ，最复杂方法名（Name of Most Complex Method）：{no methods} ，说明由于没有定义方法，不存在方法复杂度的相关统计。

题目集9：
航空货运管理系统（继承与多态）设计思路
航空货运管理系统的核心是处理客户订单和货物运输，需要根据航班载重限制、货物特性和客户类型进行合理调度。设计遵循面向对象编程思想，通过继承与多态实现功能扩展，提高代码的可维护性和可扩展性。主要涉及客户类、货物类、航班类、订单类和支付方式接口，同时要处理好输入输出以及订单的处理逻辑。
各部分详细设计
对于航空货运管理系统，共设计七个类和一个接口：

Customer（客户抽象类）
IndividualCustomer（个人客户类）
CorporateCustomer（企业客户类）
Cargo（货物抽象类）
NormalCargo（普通货物类）
ExpediteCargo（加急货物类）
DangerousCargo（危险货物类）
PaymentMethod（支付方式接口）
Flight（航班类）
Order（订单类）
Main（主类）

客户类层次结构
Customer（客户抽象类）
属性设计：

customerId：客户编号
name：客户姓名
phone：客户电话
address：客户地址
cargoList：客户的货物列表

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
addCargo (Cargo cargo)：添加货物到列表
calculateDiscount ()：计算客户折扣（抽象方法）
IndividualCustomer（个人客户类）
继承自 Customer
方法设计：

calculateDiscount ()：返回 5% 折扣
CorporateCustomer（企业客户类）
继承自 Customer
方法设计：

calculateDiscount ()：返回 10% 折扣
货物类层次结构
Cargo（货物抽象类）
属性设计：

cargoId：货物编号
name：货物名称
width：货物宽度
length：货物长度
height：货物高度
weight：货物重量

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
calculateVolumeWeight ()：计算体积重量（抽象方法）
getRate ()：根据计费重量确定费率（抽象方法）
getChargeableWeight ()：获取计费重量（实际重量和体积重量的较大值）
calculateFreight ()：计算货物运费
NormalCargo（普通货物类）
继承自 Cargo
方法设计：

calculateVolumeWeight ()：体积 / 6000
getRate ()：根据重量区间返回不同费率
ExpediteCargo（加急货物类）
继承自 Cargo
方法设计：

calculateVolumeWeight ()：体积 / 5000（更严格的体积系数）
getRate ()：普通货物费率 ×1.5
DangerousCargo（危险货物类）
继承自 Cargo
方法设计：

calculateVolumeWeight ()：体积 / 6000
getRate ()：普通货物费率 ×2
支付方式接口
PaymentMethod（支付方式接口）
方法设计：

getDescription ()：获取支付方式描述
calculateFinalAmount (double originalAmount)：计算最终支付金额
WechatPayment（微信支付类）
实现 PaymentMethod 接口
方法设计：

getDescription ()：返回 "微信"
calculateFinalAmount ()：原始金额 ×1.01（1% 手续费）
AlipayPayment（支付宝支付类）
实现 PaymentMethod 接口
方法设计：

getDescription ()：返回 "支付宝"
calculateFinalAmount ()：原始金额（无手续费）
CashPayment（现金支付类）
实现 PaymentMethod 接口
方法设计：

getDescription ()：返回 "现金"
calculateFinalAmount ()：原始金额 ×0.98（2% 折扣）
航班类
Flight（航班类）
属性设计：

flightNumber：航班号
departureAirport：起飞机场
arrivalAirport：降落机场
date：航班日期
maxWeight：航班最大载重量
currentWeight：航班当前载重

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
getRemainingWeight ()：获取剩余载重量
canCarry (double weight)：判断航班是否能承载指定重量
addWeight (double weight)：增加航班载重
isOverloaded ()：检查航班是否超载
订单类
Order（订单类）
属性设计：

orderId：订单编号
orderDate：订单日期
senderAddress：发件人地址
senderName：发件人姓名
senderPhone：发件人电话
recipientAddress：收件人地址
recipientName：收件人姓名
recipientPhone：收件人电话
customer：关联的客户
flight：关联的航班
paymentMethod：支付方式

方法设计：

构造方法：空参构造和全参构造
各属性的 get,set 方法
calculateTotalWeight ()：计算订单总重量
calculateTotalFreight ()：计算订单总运费
getFinalPaymentAmount ()：计算最终支付金额（应用折扣和支付方式）
getPaymentDescription ()：获取支付方式描述
validateOrder ()：验证订单信息完整性
主类
Main（主类）
功能：读取用户输入，解析输入并创建对象，处理订单逻辑，输出结果。

数据结构选择：

对于货物列表，使用 ArrayList 存储，方便动态添加货物。
对于订单处理，按输入顺序处理，无需特殊数据结构。

Souce Monitor分析结果：

Lines（行数）：505 行 ，代码量相对较多，说明功能实现较为复杂，涵盖较多业务逻辑处理。
Statements（语句数）：118 条 ，反映了代码中实际可执行操作的数量，语句数与行数比例不算高，可能存在较多空行、注释行或长语句合并情况 。
Percent Branch Statements（分支语句占比）：4.2% ，意味着代码中类似if - else、switch等分支逻辑占比较低，代码整体逻辑走向相对简单直接，可能是顺序执行逻辑为主 。
Method Call Statements（方法调用语句数）：29 次 ，说明代码中方法之间的交互不算频繁，各功能模块相对独立，或者部分功能通过类的属性操作等方式实现，而非频繁方法调用 。
Percent Lines with Comments（注释行占比）：5.3% ，注释占比较少，不利于代码的可读性和可维护性，后期他人阅读或自己回顾代码时，理解代码意图可能存在困难 。
Classes and Interfaces（类和接口数量）：3 个 ，表明代码定义了一定数量的类或接口，有一定的面向对象设计结构，但数量不算多，可能系统规模和复杂度有限 。
Methods per Class（每个类的方法数）：10.00 个 ，平均每个类的方法数较多，说明类的功能相对丰富，承担了较多职责，但也可能存在职责不够单一的问题，需要关注代码的内聚性 。
Average Statements per Method（每个方法平均语句数）：3.57 条 ，方法内语句数量较少，说明方法功能相对简单，可能是将复杂逻辑进行了拆分，符合代码设计的高内聚、低耦合原则；但也可能是方法拆分过度，导致逻辑过于分散 。
Line Number of Most Complex Method（最复杂方法行号）：43 ，Name of Most Complex Method（最复杂方法名）：DangerousCargo.getRemainingWeight () ，从这里可知最复杂方法所在行号以及所属类和方法名。不过这里DangerousCargo.getRemainingWeight()方法名称可能存在错误（正常应该是Flight类有getRemainingWeight方法 ），若无误则说明该方法内部逻辑相对复杂，可能涉及较多计算、判断或业务规则处理，需要重点关注其可读性和可维护性 。
三． 踩坑与心得

1. 航班载重检查的时机：
   在创建订单时没有立即检查航班载重限制，而是在后续处理中才验证。如果在订单创建后才发现航班超载，可能导致数据不一致或逻辑错误。
2. Scanner 输入的换行符处理
   Scanner.nextInt() 后没有消耗换行符，导致后续 nextLine() 读取空行。

四． 改进建议
1.代码复杂度太高，不够精简
2.类与类之间的关系不是很清晰
3.增加一些代码的注释，使代码具有更好的可读性

五． 总结
经过这两次的题目集，我学习到许多知识，包括但不限于继承，抽象类，接口，继承的逻辑，同时也发现更多不足之处，之后的时间我会更加努力去完善。