第二次Blog作业

一.前言
在这两次题目集中的前两题基本上都是难度逐渐增加，对其进行类设计，而在这两个题目集中进行迭代功能拓展的题目是航空货运订单管理，相较于之前的题目集，这道题目的代码复杂度有较大提高，对于第一道航空货运订单管理题目，其更加着重于考查java的基础语法知识以及对复杂数据的处理，而第二道航空货运订单管理题目在第一道的基础上对费率增加了普通，危险和加急三种计算方式，虽然听起来简单，但要在第一题的基础上进行迭代编写，并且使其符合继承与多态满足面向对象的设计原则。
二.设计与总结
题目集8：
计费重量的确定
空运以实际重量（Gross Weight）和体积重量（Volume Weight）中的较高者作为计费重量。
计算公式：
体积重量（kg） = 货物体积（长×宽×高，单位：厘米）÷ 6000
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如CNY 30/kg）。
本次作业费率采用分段计算方式：

公式：基础运费 = 计费重量 × 费率
这道题目要求符合单一职责原则（40%）、里氏代换原则（20%）、开闭原则（20%）、合成复用原则（20%）
类设计：
Customer(客户类)
方法：
getName()//获取名字
getPhone()//获取电话号
Cargo(货物类)
方法：
getVolumetricWeight()//计算体积
getChargeWeight()//获取货物重量
getName()//获取名字
getWeight()//获取重量
Flight(航班类)
方法：
checkAndAddLoad(double weight)
getFlightNumber()//获取航班号
Order(订单类)
方法：
getTotalWeight()
getTotalPayment()
getRate(String cargoName)
getOrderNumber()
getDate()
getSenderName()
getSenderPhone()
getSenderAddress()
getReceiverName()
getReceiverPhone()
getReceiverAddress()
getCargoList()
getFlight()
getCustomer()
Main(主类)
Source Monitor分析报表：

报表分析：
​​1. 基础指标概览​​
​​代码规模​​：
总行数：220行
有效语句数：149条
类和接口数：5个
方法数/类：5.40（平均每个类有5-6个方法）
​​复杂度与结构​​：
​​最复杂方法​​：Main.main()（位于第113行），复杂度为4（可能包含多层嵌套逻辑或条件分支）
​​最大块深度​​：4（代码中存在4层嵌套块，如if-else或循环嵌套）
​​平均块深度​​：1.68（整体嵌套层级较低，但局部存在深度逻辑）
​​可读性与维护性​​：
​​注释覆盖率​​：仅4.1%的代码行含注释（远低于推荐值20%，可能影响可维护性）
​​分支语句占比​​：8.1%（条件逻辑较少，但需检查测试覆盖率是否充分）
2. 关键图表解析​​
​​Kiviat图（雷达图）​​：
综合指标包括：方法数/类、平均复杂度、平均块深度、平均方法语句数等。
​​显著特征​​：
​​方法数/类​​（5.40）较高，可能暗示某些类职责过重（违反单一职责原则）。
​​平均复杂度​​较低，但Main.main()的局部复杂度较高（需重点关注）。
​​块直方图（语句深度分布）​​：
大部分代码块深度为1-2层（浅绿色），但存在深度为4的代码块（红色柱，第115行）。
​​风险点​​：深度为4的嵌套逻辑可能导致可读性差和潜在缺陷。
改进建议：
​​高风险代码段​​：
​​第113行​​：Main.main()方法复杂度高，建议拆分为多个辅助方法。
​​第115行​​：4层嵌套块，需简化逻辑或用策略模式/状态机优化。
​​代码规范优化​​：
​​注释不足​​：添加方法、复杂逻辑的注释，提升可维护性。
​​类职责过重​​：检查5个类中方法分布，拆分高方法数的类（如提取工具类或子模块）。
​​测试覆盖建议​​：
​​分支测试​​：8.1%的分支语句需补充单元测试，尤其是Main.main()中的条件逻辑。
改进重点：
重构高复杂度的Main.main()方法和深度嵌套块。
增加注释密度至15%-20%。
优化类设计，避免职责过重
题目集9：(这道题是基于题目集8那道题进行拓展)

类设计：
Customer(客户类)
方法：
getName()//获取名字
getPhone()//获取电话号
getUserType()
getId()
getAddress()
Cargo(货物类)
方法：
getCargoType()
getChargeableWeight()
getId()
getName()//获取名字
getWeight()//获取重量
getHeight()
getLength()
getWidth()
Flight(航班类)
方法：
getDeparture()
getArrival()
getDate()
getMaxLoad()
getFlightNumber()//获取航班号
Order(订单类)
方法：
getOrderNumber()
getOrderDate()
getSender()
getRecipient()
getPaymentMethod()
Sender(发货类)
方法：
getAddress()
getName()
getPhone()
Recipient(收货类)
方法：
getAddress()
getName()
getPhone()
Main(主类)
Source Monitor分析报表：

基于Java代码度量图的分析报告
​​1. 代码基础指标​​
​​代码规模​​：
总行数：294行（中等规模，接近300行）
有效语句数：195条（代码密度较高，空行较少）
分支语句占比：4.6%（逻辑复杂度较低，但需检查测试是否覆盖）
​​注释覆盖率​​：0%（严重缺陷，完全无注释，违反可维护性原则）
​​类与方法设计​​：
类和接口数：7个
每个类的方法数：平均5.14个（接近合理范围，但需检查是否有"上帝类"）
方法平均语句数：3.33（单个方法逻辑较简洁）
​​2. 复杂度与结构风险​​
​​核心风险点​​：
​​最高复杂度方法​​：Main.main()（第6行）复杂度为6
典型表现：可能包含多层循环/条件嵌套（如订单处理、输入解析等）
风险：维护困难、单元测试覆盖率低
​​最深代码块​​：第111行，块深度5
典型场景：for-if-switch多级嵌套（如数据校验、多重业务逻辑分支）
风险：可读性差，易引入隐藏缺陷
​​结构健康度​​：
平均块深度：2.50（整体结构中等复杂度）
方法调用语句：56条（依赖链较长，需警惕循环依赖）
改进建议：
代码注释完全没有，要适量增加代码注释，为每个类增加注释解释。
代码结构优化，主类复杂度太高，不符合单一职责原则
类职责过重，分支测试覆盖率不足
三.心得
1.在这两次题目集中虽然说题目看起来简单，但其中也掺杂着许多细节和难点，对于我的代码，其中任然有不少问题，如代码注释残缺很少，不利于代码解读以至于过段时间就会忘记代码的意义。
2.在完成代码的时候，遇到了Scanner处理输入时输入换行符的问题。
3.对于题目集9中的航空货运订单管理题目，在书写代码时一直遇到非零返回的问题以至于最后也没有做出了，但后来又反复思考，其实是当时输入逻辑有问题，在重新修改输入逻辑后也是正确输出结果。
四.改进建议
1.增加代码注释以增加代码可读性。
2.履行单一职责原则，多增加几个类，每个类只履行一个职责。
3.尽量降低代码复杂度。
五.总结
经过这两次题目集的学习，我已经基本上掌握了继承，多态，抽象类，抽象方法，接口等知识，虽然说题目集9的扩展题目在规定时间内没有做出来，但通过不断学习以后一定会更加努力地去完善自己的不足。