一、前言

對整門課程的概要性總結，從工作量與難度兩大角度展開分析，總體説明學習體驗。

（一）工作量評估

（二）難度評估

二、面向對象技術總結

在面向對象技術的學習過程中，通過PTA作業、實驗等多個教學環節，我對封裝、繼承、多態等核心概念及相關技術有了深入的理解與實踐。以下將結合具體教學環節，總結個人對各項技術的掌握情況。

📦 1. 封裝

在PTA作業和實驗中，封裝的應用無處不在。以航空貨物管理系統實驗為例，我將貨物的名稱、編號、長寬高等屬性進行私有化，通過提供公有的getter和setter方法來訪問和修改這些屬性。這不僅保證了數據的安全性，還實現了數據的隱藏，使外部代碼無法直接對屬性進行非法操作。很好的體現了代碼的封裝性。

通過PTA作業和實驗的鍛鍊，我深刻認識到封裝是面向對象編程的基礎。它將數據和操作數據的方法捆綁在一起，形成一個獨立的單元。使外部的代碼不能直接改變其中的屬性。在初期學習時，我經常混淆屬性的訪問權限，導致數據的安全性無法得到保障。經過多次作業和實驗的打磨，我逐漸掌握了封裝的要領，但在複雜業務邏輯中，如何合理地封裝方法和屬性，但要真正實現高內聚低耦合，還需要進一步學習和實踐。

🔗 2. 繼承

繼承是實現代碼複用的重要手段，可以很有效的減少代碼的使用量，並且也符合人的思維模式。例如在實驗中，要求我們實現把不同動物裝進不同電器這一過程中，就要求我們能夠很好的運用繼承關係。定義合適的父類電器類和動物類，並且實這一類事物共有的方法和屬性。

這一過程讓我清晰地理解了繼承的層次結構和優勢，通過繼承，子類可以複用父類的代碼，減少了重複書寫的代碼。但在使用繼承時，我也遇到了一些問題，比如繼承關係過於複雜導致代碼難以維護，以及方法重寫時的權限問題。目前，我對繼承的基本使用較為熟練，但在優化繼承結構、避免繼承帶來的代碼複雜性方面以及判斷是否要使用繼承關係方面還有所欠缺。

🔮 3. 多態

多態的概念在PTA題目點線面當中中得到了充分體現。我定義了一個基本元素抽象父類，然後通過繼承創建了點類、線、面類等具體圖形類。在展示這些基本元素時時，使用抽象類的引用指向具體點線面類的對象，調用統一的展示方法，根據對象的實際類型執行不同的展示邏輯。很好的實現了多態的優勢。

這種動態綁定的特性讓代碼更加靈活和可擴展，當需要添加新的圖形類型時，只需要創建新的子類並實現繪製方法即可，無需修改原有代碼。在PTA作業中，我也多次運用多態的思想解決問題，但在涉及複雜的多態層次結構和方法重載時，有時會出現混淆，對多態的深層次應用還不夠熟練。

⚙️ 4. 抽象類

抽象類作為一種特殊的類，在課程學習中起到了規範和約束的作用。在航空貨物管理系統的作業裏，我定義了一個抽象支付類，其中包含了抽象的支付方法。具體的支付方式，如微信支付類、支付寶支付類等，都繼承自這個抽象支付類，並實現抽象的支付方法。

通過抽象類，我明確了不同支付方式的共性和差異，為具體支付類的實現提供了統一的標準。但在抽象類的設計上，我有時難以準確判斷哪些方法應該定義為抽象方法，哪些屬性應該放在抽象類中，對抽象類的設計原則和應用場景還需要進一步加深理解。

🔌 5. 接口

接口在課程中的應用場景十分廣泛，它與抽象類不同，更強調實現類的行為規範。在航空貨物管理系統的PTA作業中，我定義了一個商品費率計算接口，包含了商品的基本操作方法，如普通貨物、加急貨物、危險貨物等，都實現了這個接口，從而保證了不同的貨物都具備統一的操作方法，但卻可以使用不同的費率計算方法。讓代碼的擴展性和可維護性大大提高。

接口的使用讓代碼的擴展性和可維護性大大提高，實現了不同類之間的鬆耦合。但在接口的多繼承和接口與抽象類的選擇上，我還存在一些困惑，需要進一步學習相關知識，明確它們的適用場景。

🗃️ 6. 集合框架

集合框架在處理大量數據時發揮了重要作用。在統計Java程序中關鍵詞的出現次數的PTA作業中，我使用ArrayList來存儲Java中關鍵字信息，通過它提供的各種方法，分割並儲存元素，刪除註釋元素，遍歷元素去查找，方便地對Java關鍵字數據統計進行操作。在處理鍵值對數據時，我使用了HashMap，實現了Java關鍵字與次數的快速映射。

通過實踐，我掌握了常見集合類的基本使用方法，但對於集合框架的底層實現原理，如ArrayList的擴容機制、HashMap的哈希算法等，瞭解還不夠深入。在處理大量數據時，如何根據具體需求選擇合適的集合類，以提高程序的性能，也是我需要進一步學習的內容。

⚠️ 7. 異常

異常處理在保證程序穩定性方面至關重要。在文件讀寫的航空貨物管理系統的PTA大作業中，我經常會遇到文件不存在、文件讀取錯誤等異常情況。通過try-catch-finally語句塊，我可以捕獲並處理這些異常，避免程序因異常而崩潰。同時，我還自定義了一些異常類，用於處理特定業務邏輯中的異常情況。

雖然我掌握了異常處理的基本語法和常用方式，但在使用上老是會報錯。而且我在異常的合理拋出和捕獲層次設計上還存在不足，有時會出現過度捕獲或捕獲不全面的情況，影響程序的健壯性。

💻 8. JavaFX

JavaFX在圖形界面開發方面展現出強大的功能。在航空貨物管理系統的PTA大作業中，我使用JavaFX創建了美觀的用户界面，包括窗口、按鈕、文本框等組件，並通過事件監聽機制實現了組件之間的交互。同時通過翻轉課堂這種新穎的形式也更能讓我對這一部分去有更深入的瞭解，才能更好的完成內容的設計和講解。

然而，JavaFX的佈局管理和樣式設置相對複雜，我在佈局的自適應和樣式的個性化定製方面遇到了不少困難。對於JavaFX的動畫效果和多媒體處理功能，我還沒有深入學習和實踐，掌握程度有待提高。

三、踩坑心得

  在整門課程的學習過程中，我走過不少彎路，也積累了許多寶貴的經驗教訓。以下是三個最深刻的踩坑經歷及反思：

🚧 1. ​​理解題目要求後再去編程​​

"盲目編碼導致的返工，比理解需求花費的時間多十倍不止"

在​​第一次電梯調度PTA作業​​中，我犯了一個致命錯誤：看到題目後立即開始寫代碼。題目要求實現單部電梯的動態調度算法，但當時的我我並不瞭解單部電梯的Look調度算法。直到提交時才發現不符合需求，提交了30、40次有依舊不對，後來只能在段老師提供的算法解析後，不得不​​通宵重寫​​80%的代碼。

​​其他具體教訓：​​

• 在航空貨物管理系統實驗中，因未注意"不同客户有不同的計算折扣"的要求，導致​​總金額錯誤​​，導致題目無法正常完成。

• PTA題目集7中，因為忽視"必須使用接口實現多態"的限制條件，導致​​設計模式錯誤​​被扣30%分數

• 完成實驗五時，沒有看清楚實驗五要求的界面佈局，盲目的根據自己的想法去設計ui界面，後來發現界面佈局必須按照實驗指導書上的來，導致佈局代碼要全部修改。

​​應對策略：​​

• 建立​​需求清單​​：將每個要求轉為具體檢查項
• 繪製​​流程圖​​：先用流程圖驗證邏輯可行性
• 互相討論：與同學交叉驗證需求理解

🔥 2. 實踐遠大於理論學習

"看十遍教程不如親手敲一遍代碼"

在JavaFX學習中，我看了兩週教程，但實際開發航空貨物界面時卻對界面設計，事件邏輯的處理，文件的操作和異常處理當中表現的束手無策。
問題分析
在理論學習中雖然可能聽懂了，但是在實際編程過程中總會遇到一些不知道的問題，或者是對知識點的遺忘導致無法下手。
解決方法

• 在進行了一定的理論學習過後，一定要進行自我的編程訓練，在報錯中調試，在不斷的問題解決中得到編程和理論知識的運用的提升。
• 同時我們也可以去故意製造系統的錯誤從而去更好更深入的去了解底層機制，進而使自己的知識面更加廣闊。
• 切記不能以為自己以為聽懂了理論知識就代表自己對這一部分的內容以及完全掌握。聽懂了≠會運用。

🧩 3. ​​代碼優化的持續追求​​

"完成功能只是開始，優雅實現才是目標"

在這種迭代模式的PTA作業當中，如果我們僅僅滿足於第一次代碼設計的結構，而不去不斷優化自己的代碼，提高代碼的可擴展性和維護性的話。那麼在下一次是迭代中我們就可能會花比別人多一倍的時間去優化自己的代碼結構。

以及在PTA作業Java關鍵字或是電梯調度的代碼中，我們也可以去優化自己的算法，降低複雜度。
​​優化對比案例：​​

// 初始版本 - 嵌套循環O(n²)
for(String word : allWords) {
    for(String keyword : keywords) {
        if(word.equals(keyword)) {
            count++;
        }
    }
}

// 優化版本 - HashSet查找O(1)
Set<String> keywordSet = new HashSet<>(keywords);
for(String word : allWords) {
    if(keywordSet.contains(word)) {
        count++;
    }
}

​​常見問題：​​

• 可擴展性低​​：在航空貨物系統使用直接數值計算運費
• 類設計不合理​​：將貨物管理、支付、報表全放在Main類
• 耦合度高：處理界面邏輯代碼直接寫在JavaFX代碼中

可以參考的代碼​​優化路線：​​

• 基礎重構​​：消除重複代碼→抽取方法
• 設計進階​​：應用設計模式→工廠+策略
• 性能提升​​：時間複雜度分析→算法優化
• 工程化​​：規範的文件管理結構

💡 核心領悟
通過多次踩坑經歷和學習歷程，我們也可以推導並總結出​​面向對象開發的公式​​：

​​完整需求理解 × 不斷實踐修改 × 持續代碼優化 = 高質量交付​​

這三者不是順序關係而是乘積關係，任何一項缺失都會導致整體質量歸零

在期末的航空貨物管理系統大作業中，我嚴格踐行這個公式：

1. 先用2天時間分析需求，設計具體的界面佈局和功能，以及事件處理。
2. 不停的進行​​代碼重構和​​優化。
3. 功能實現後消除一些不必要的代碼
4. 引入設計模式優化結構
5. 不斷增加界面ui控件、優化界面佈局使界面美觀

四、改進建議及總結

（一）課程總結

面向對象編程之旅

整門課程以面向對象技術為核心，通過PTA作業、實驗，學堂在線線上課程等多樣化的教學形式，構建了理論與實踐相結合的教學體系。最大的亮點是採用漸進式迭代設計，從基礎的封裝、繼承到複雜的設計模式應用，以及迭代式的題目集，形成了層層遞進，環環相扣的教學方法。還有一些創新的地方：

1. 翻轉課堂
   在JavaFX章節，學生通過課前自己找資料學習、製作PPT、課堂中學生來講課的在這種方式，有效培養了自主學習能力、團隊溝通能力以及語言組織能力。這種方式讓我對JavaFX界面開發有了深刻理解

2. 開發的全過程
   在最近幾次的作業當中，航空貨物管理系統貫穿多個教學環節，從簡單的類設計到複雜UI開發，體現了軟件設計的完整過程

3. 學生能提出建議 在Blog中，有了學生的意見，課程組能夠針對廣大學生的痛點，進行改進，從而不斷優化課程設置，共同進步。

但課程也存在明顯不足：實驗工作量與回報比例失衡的問題有待改進。

（二）改進建議

1. 實驗環節優化

問題現狀

• 重複性的工作過多 花了時間但沒有得到實際面向對象設計能力的提升

• 調試時間遠超合理範圍 每次調試修改問題都要好久。而且這種沒有目的的調試也不能高效的提升學生調試問題的能力（時間全浪費在找問題上面了）

• 打擊學習積極性： 毫無必要的困難和挫折感會迅速澆滅學生的學習熱情，讓他們覺得編程就是痛苦和折磨。

改進建議

• 在實驗系統當中加入實時報錯的顯示，讓學生能夠更加高效的調試自己的程序。

• 加入自動補全和插入基本代碼的功能，比如一些重複性高，無實際訓練意義的代碼（Getter，Setter之類的）可以自動生成或者插入。

上面這些建議能解決當下的一些問題，但是長遠來説，還是需要鍛鍊學生們在企業常用軟件怎麼來編程的能力，滿足企業需求，增加學生就業競爭力。理解底層原理確實很重要，但在真正的編程當中，能夠更快上手，高效的調試並解決問題才是關鍵。

（三）學習成果總結

技術能力提升

在整個面向對象過程的學習中我對Java的基本語法，封裝、繼承、多態、抽象類、接口、集合框架、異常以及JavaFX等相關內容都有了一個較為全面的掌握。

思維模式轉變

從C語言當中的面向過程的編程轉變為了現在Java的面向對象編程。從關注"如何實現功能"轉變為"如何組織對象協作"。

（四）未來提升方向

深入瞭解底層原理

補全集合框架、JVM內存管理等底層知識

複雜系統設計和團隊協作能力​​

學習如何去設計一個複雜的系統，並且去了解怎麼做到良好的團隊合作，提高效率。

擴展一些設計模式

去了解並學習一些優秀設計模式，提高自己代碼的質量。

正如軟件工程大師Martin Fowler所説：
​​"任何傻瓜都能寫出計算機能理解的代碼，優秀的程序員寫出的是人能理解的代碼"​​
你在學習本門課程時遇到了哪些挑戰？歡迎在評論區分享你的解決方案！感謝您的閲讀！