前言
本次大作業是第一個面向對象編程的實操練習，難度從中到難，層層遞進。
- OOP題目集01
大部分是作為前面Java程序練習的過渡用的練習題，題目簡單，題型常見不復雜，能幫助我們學習更多方法運用於Java編程當中。
第一次電梯調度程序也是基礎的電梯類設計，初步瞭解題目的需求，為以後的迭代設計奠定基礎。 - OOP題目集02
本次題目集對類設計有了更嚴格的要求標準，題目複雜度逐漸上升，涉及類的創建和使用，能夠更好地加深面向對象編程思想。
第二次電梯調度程序在第一次的基礎上進行了迭代涉及，瞭解單一職責原則。 - OOP題目集03
本題目集需要解決更深層次的應用，涉及到類的繼承等等。
這次的電梯調度程序則進一步開始迭代性設計。
設計與分析
由於能力上的不足等原因，有關單部電梯調度的程序未能成功調通（或未完成），故在此主要分析我代碼上的缺陷不足和問題所在。
題目集1：單部電梯基礎調度
類圖設計
源碼分析要點
首先，編譯並運行之後顯而易見的出現了錯誤：運行時錯誤，會一直循環打印，並且樓層數量始終為0，顯然出現了很多邏輯錯誤。
這邊是用ai工具分析的情況：
- 邏輯混亂
在Main類中，使用字符串長度（input.length()>=3&&input.length()<6）來區分內部和外部請求不可靠。例如，外部請求<10,UP>長度為7，會被錯誤分類；內部請求如100（3字符）可能被誤判為外部請求。
改進建議：最好使用正則表達式或解析請求內容來區分類型 - 數據封裝不足，違反OOP原則
Elevator類的字段（如IQ、OQ）被聲明為public，並在Main類中直接訪問（例如elevator.OQ.add(input)），破壞了封裝性。
改進建議：將字段設為private，並通過公共方法（addRequest(String request)）來添加請求，內部根據請求類型自動分類
分析報告
報告顯示：
代碼質量指標：
- 分支覆蓋率：27.6% - 測試覆蓋率較低
- 註釋率：21.7% - 註釋相對充分
- 方法複雜度：平均每個方法7.06條語句
複雜度問題：
- 最大圈複雜度：4（標有*號，表示有方法較複雜）
- 平均複雜度：1.85（標有*號，超出理想範圍）
- 最大嵌套深度：4層
題目集2：單部電梯增強調度
類圖設計
源碼分析要點
由於時間問題，我並沒有完成最後的代碼，因此以下是使用ai工具分析其他代碼部分的結果：
- 調度算法邏輯問題
在hasRequestsInDirection方法中，條件elevator.getCurrentFloor() == req.getFloor()可能邏輯不正確，電梯當前樓層等於請求樓層時應該直接處理 - 方法複雜度依然偏高
determineDirection()和hasRequestsInDirection()`方法邏輯較複雜。 - 缺少輸入解析層
分析報告
報告顯示：
代碼質量指標：
- 分支覆蓋率：17.8% - 測試覆蓋率下降
- 註釋率：9.3% - 註釋比例減少
- 方法複雜度：3.10 - 方法規模明顯減小
複雜度問題：
- 最大圈複雜度：4（標有*號，表示有方法較複雜）
- 平均複雜度：1.14（標有*號，但相比第一次的1.85顯著降低）
- 最大嵌套深度：4層
- 平均嵌套深度：1.41層
題目集3：單部電梯優化調度
類圖設計
源碼分析要點
- 重複請求過濾不完整
雖然內部請求有去重，但外部請求沒有。 - 樓層有效性檢查缺失
添加請求時沒有檢查樓層是否在有效範圍內。 - 方向匹配邏輯可以優化
在shouldStop和removeRequests中重複了相似的方向檢查邏輯。 - 硬編碼的初始輸出
Main類中硬編碼了初始方向輸出。
分析報告
報告顯示：
代碼質量指標：
- 分支覆蓋率：22.3% - 測試覆蓋率有所改善，但仍偏低
- 註釋率：22.3%
複雜度問題：
- 最大圈複雜度：3
- 平均複雜度：1.54（相比第二版的1.14有所上升）
- 最大嵌套深度：6層
- 平均嵌套深度：1.85層
踩坑心得
第一次設計最大的問題就是邏輯混亂複雜，所有功能都往一個類裝，調度邏輯、狀態管理、隊列處理混雜在一起。
第二次有了參考類圖設計，結構方面稍微改善了點，但由於第一次未能打好基礎，所以第二次也沒有成功寫出完整的程序。
第三次終於能正常運行了，但依然存在答案錯誤，未通過測試點的問題，這説明我在新增功能時沒有同步增加測試，而且嵌套深度過深，條件判斷過於複雜了。
隨着程序的複雜度上升，應在註釋方面多注意，方便未來調試。
改進建議
可以針對架構設計、複雜度控制等方面進行改進，詳細的前面已註明，不再多説。
總結
收穫與成長
通過本階段的練習，我能夠學會如何設計類以及合理進行職責劃分，並且能從只關注功能到關注複雜度、覆蓋率，學習了迭代優化思維，能夠通過持續重構改善代碼質量。
