前言

就第八、九次題目集而言，知識點主要以類設計為主，并不涉及算法，難度相較上次大大降低。題目主要分為兩類：

1. 對輸入的數據進行簡單的處理并格式化輸出
2. 對之前的題目重構，擴展新的功能

因此，本輪題目集的重點是考察對繼承與多態的理解與運用，而非直接編程。
本次分析將以兩次題目集中的“航空貨運管理系統”題目為重點分別進行分析并作出總結。

設計與分析

第一次航空貨運管理系統

類圖設計

代碼分析

• 代碼共 543 行，包含 262 條語句，分支語句占比 4.2% ，方法調用語句 73 條。有 8 個類和接口，平均每個類含 8.75 個方法 ，每個方法平均語句數 2.26 。
• 平均復雜度 1.16 ，整體處于較低水平。最大復雜度為 Cargo.getRate() 方法的 5 ，位于 430 行，最大塊深度 3 ，最深代碼塊在 21 行，平均塊深度 1.65 。
• 涉及 Cargo、Controller、Customer、Flight、Order、Person 等 7 個類的方法。多數方法復雜度為 1 ，語句數和深度較小。如各 類的眾多 getter 和 setter 方法。但 Cargo.getRate() 復雜度 5 ，含 10 條語句，最大深度 3 ；Controller.dealOrder() 復雜度 3 ；Controller.printOrderMessage() 復雜度 2 ，含 15 條語句，最大深度 17 ；Main.main() 復雜度 2 ，含 42 條語句，最大深度 33 ，這些方法相對復雜。
• 深度為 2 時語句數最多，達 135 條；深度 1 有 94 條語句；深度 3 有 23 條語句；深度 4 - 9 + 語句數為 0 。說明代碼邏輯集中在較淺深度層次。

總結與心得

通過第一次對程序的實現，對于貨物管理系統有了一定的理解并且得到了一個具備一定擴展性的程序。但是程序依然存在許多問題：

• Order類直接與Customer類關聯，使得Controller類并沒有達到將兩者解耦的目的，顯得畫蛇添足。
• Controller類的設計不合理，超出了單一職責原則，比如getAllCost()方法應該屬于Order類。

第二次航空貨運管理系統

類圖設計

代碼分析

• 代碼共808 行，72 條語句，分支語句占比 8.3%，方法調用 31 次。包括18個類和3個接口。平均復雜度為1.42，最大復雜度為 3在Main.main()中。
• 繼承體系：

1. Customer 分層：Customer（抽象）→ IndividualCustomer/CorporateCustomer，實現Discounted接口（折扣策略）。
2. Cargo 分層：Cargo（抽象）→ NormalCargo/DangerousCargo/ExpediteCargo，實現 Ratable接口（費率計算）。
3. Payment 分層：Payment（抽象）→ Wechat/ALiPay/Cash，多態實現支付方式。

• Visual接口規范Controller的打印邏輯，分離業務處理與視圖展示。各子類通過重寫getRate()/getDiscount()/payType()實現多態行為，符合 OOP 設計原則。
• 高復雜度方法：
  Main.main()（復雜度 3，語句 12，塊深度 4）、
  Controller.dealOrder()（復雜度 3，語句 6，塊深度 8）、Controller.printOrderMessage()（復雜度 2，語句 15）。
• 代碼塊深度分布：
  深度 0-1 的語句占比 76.4%（55 條），深度 4 的語句僅占 1.4%，整體嵌套層次可控，但Main.main()和Controller方法存在冗余分支。

總結與心得

• 類設計缺陷，Main類承擔輸入解析、對象組裝等多重職責，違反單一職責原則。
• Controller同時處理訂單邏輯和打印輸出，存在拆分的空間。
• 各Cargo子類的getRate()方法存在相似的條件判斷邏輯，可通過策略模式統一封裝費率規則。

踩坑心得

復雜的輸入環節

本次的航空貨運管理系統存在的一個顯著特點就是要輸入豐富多樣的數據，即有int型，double型和String型。不僅如此，輸入過程也比較復雜。其中一個很麻煩的問題就是Scanner的緩沖區殘留問題，在何時使用nextLine()吸收空行是一個問題。
解決方案：
利用單步斷點調試，對每一步進行檢查，添加在合理的地方添加nextLine()。

仔細讀題

• 在題目輸出部分中的“訂單總重量”指的是計費重量而非實際重量，在閱讀評論區后解決。
• 費率計算如下圖，但在代碼實現的過程忽略了等于的情況，導致代碼邏輯錯誤，后仔細檢查代碼才發現問題。
  

改進建議

1. 對Cargo的費率計算使用策略模式，定義RateStrategy接口，各子類實現具體策略，消除重復條件判斷。
2. 引入工廠模式創建Customer和Cargo實例，避免Main類中的大量switch-case。
3. 拆分Controller為業務邏輯和打印邏輯，降低耦合度。
4. 將/6000、折扣率（0.9/0.8）、費率（35/80 等）提取為類常量。

總結

通過第八、九次題目集“航空貨運管理系統”的實踐，深入應用繼承與多態等面向對象思想。實現了建立基礎類結構，二次迭代細化繼承體系（如Customer分層、Cargo子類擴展），并且通過實現接口處理折扣、費率計算及支付方式，通過接口分離業務與視圖邏輯。但設計中存在Main類職責過重、Controller功能耦合、代碼復用不足等問題，部分核心方法嵌套邏輯復雜。
在實踐中理解了明確需求細節的重要性。在未來可通過策略與工廠模式優化代碼結構，拆分模塊職責，提取常量提升可維護性，強化模塊化與可測試性設計，從功能實現向架構優化進階。