一 ：作業總結

　　首先總言就是感覺大部分作業還算正常??，但是仍然存在部分作業內容留有問題，難度適中，工作量偏急，量大。

　　Blog作業算上現在也就只有三次，量倒是不大，難度也沒有什么。但是有點迷茫的是不清楚做這個作業到底會有什么實質性的成長，目前還是比較不清楚的。

　　Pta作業比較合乎我對于作業的預期，難度適中，十分有效得幫助了自己對于java的學習和練習，可惜測試點描述含糊，有點消磨時間。

　　實驗作業對我個人而言就是一個巨大的雷區了，并不是說題目難度或者提交方式不好，而是它無法“復制粘貼“的屬性極大程度上加大了自己的工作量，甚至會激發自己放棄的想法，畢竟在以效率之上的時代，明明有著更好的編譯環境可以使用，大部分人毋庸置疑會優先選擇idea等優質編譯軟件輔助自己的編譯，極大提高自己的編譯效率與后期修改，但是由于無法復制的屬性導致進入實驗提交系統需要二次輸入，而且是一個字一個字地輸入，且先不說輸入錯誤的難度大和時間上的消耗。修改起來也是極其不便，哪怕是切入ide里面去找到了錯誤的點，還要返回來在一堆看起來不是十分舒適的字體與排版中去尋找問題修改點，我覺得這點有點折磨??。

　　線上課程與線下課程工作量難度適中。

（1）第一次大作業：

題目：

設計一個電梯類，具體包含電梯的最大樓層數、最小樓層數（默認為1層）當前樓層、運行方向、運行狀態，以及電梯內部乘客的請求隊列和電梯外部樓層乘客的請求隊列，其中，電梯外部請求隊列需要區分上行和下行。
電梯運行規則如下：電梯默認停留在1層，狀態為靜止，當有乘客對電梯發起請求時（各樓層電梯外部乘客按下上行或者下行按鈕或者電梯內部乘客按下想要到達的樓層數字按鈕），電梯開始移動，當電梯向某個方向移動時，優先處理同方向的請求，當同方向的請求均被處理完畢然后再處理相反方向的請求。電梯運行過程中的狀態包括停止、移動中、開門、關門等狀態。當電梯停止時，如果有新的請求，就根據請求的方向或位置決定移動方向。電梯在運行到某一樓層時，檢查當前是否有請求（訪問電梯內請求隊列和電梯外請求隊列），然后據此決定移動方向。-每次移動一個樓層，檢查是否有需要停靠的請求，如果有，則開門，處理該樓層的請求，然后關門繼續移動。
使用鍵盤模擬輸入乘客的請求，此時要注意處理無效請求情況，例如無效樓層請求，比如超過大樓的最高或最低樓層。還需要考慮電梯的空閑狀態，當沒有請求時，電梯停留在當前樓層。

要求：

請編寫一個Java程序，設計一個電梯類，包含狀態管理、請求隊列管理以及調度算法，并使用一些測試用例，模擬不同的請求順序，觀察電梯的行為是否符合預期，比如是否優先處理同方向的請求，是否在移動過程中處理順路的請求等。為了降低編程難度，不考慮同時有多個乘客請求同時發生的情況，即采用串行處理乘客的請求方式（電梯只按照規則響應請求隊列中當前的乘客請求，響應結束后再響應下一個請求），具體運行規則詳見輸入輸出樣例。

思路：

此次處理采用了一個先判斷，后運動的大概思路，通過依次讀取的電梯內外層需求信息，
做到及時判斷，運動處理，在邏輯上十分清楚簡潔，而也只需要在判斷類里面加上一個“panduan方法，
做到依照不同的情況返回不同的數值而精準判斷運動類型”，便可以做到滿足用戶需求。

寫完代碼參數分析：

　　從矩陣圖可以直觀地看出來，第一次的大作業編寫還是不太成熟，類過少，深度過高，if—else濫用成災，雖然運行起來也沒有問題，但是后期在修改上十分困難。

（2）第二次大作業：

題目：

某航空公司“航空貨運管理系統”中的空運費的計算涉及多個因素，通常包
括貨物重量/體積、運輸距離、附加費用、貨物類型、客戶類型以及市場供需等。

本次題目模擬某客戶到該航空公司辦理一次貨運業務的過程：
航空公司提供如下信息：
航班信息（航班號，航班起飛機場所在城市，航班降落機場所在城市，航班
日期，航班最大載重量）
客戶填寫貨運訂單并進行支付，需要提供如下信息：
? 客戶信息（姓名，電話號碼等）
? 貨物信息（貨物名稱，貨物包裝長、寬、高尺寸，貨物重量等）
? 運送信息（發件人姓名、電話、地址，收件人姓名、電話、地址，所選
航班號，訂單日期）
? 支付方式（支付寶支付、微信支付）

要求：

一、計費重量的確定

空運以實際重量（Gross Weight）和體積重量（Volume Weight）中的較
高者作為計費重量。
計算公式：
體積重量（kg） = 貨物體積（長×寬×高，單位：厘米）÷ 6000
示例：
若貨物實際重量為 80kg，體積為 120cm×80cm×60cm，則：
體積重量 = (120×80×60) ÷ 6000 = 96kg
計費重量取 96kg（因 96kg > 80kg）。

二、基礎運費計算

費率（Rate）：航空公司或貨代根據航線、貨物類型、市場行情等制定（如
CNY 30/kg）。本次作業費率采用分段計算方式：

公式：基礎運費 = 計費重量 × 費率

思路：

1：在每一件貨物輸出前就有對于總價位的輸出，所以說計算總價的類是獨立的，且能在分別輸出各自貨物內容的時候就計算出總價。
2：題目中的重量的取舍取決于每一件物品的實際計算重量誰的大，所以要分出一個方法子類來計算出實際計算重量取哪個。
3：題目中有大量計算，所以最好開通一個計算類，進行各種不同的內容計算。
4：在計算利率的時候不同的范圍計算的利率不同，要單獨做個方法。
5：輸出在格式上別具一格，且無列表符號的出現，所以每一行內容都并非單純的輸出所有列表語句實現。
6：要注意對于單位的取舍和飛機載重的限制。

創建對應的類先把輸入的內容“吃掉”，然后再通過控制類將不同類吃掉的內容“消化”，以一個大的計算類進行前提要求下提到的不同板塊內容的計算，還有就是提出一個計算實際重量的方法找到真正有用的實際重量帶到后期的計算。有了前期消化的內容和消化，現在就可以轉化為輸出，對于復雜的內容可以直接輸出的絕不多加麻煩，要提前計算總重量的地方提前算好。采用這種流程式的對象設計，大大方便了我的代碼編譯和理解。

寫完代碼參數分析：

　　可以看到，這次的類圖設計相比于上一次的電梯設計有著巨大的進步，上次幾乎全部都在綠色意外，這次居然有安全區，復雜度都很低。

二：面向對象技術總結：

通過pta作業對于基礎語法的打磨，已經使得自己掌握了基礎的繼承，多態，接口等內容的運用，而繁瑣的實驗內容，則是在我原有的代碼基礎知識之上，做到一個修飾效果，令自己學會了升華自己的代碼“逼格”，使得整個代碼變得華麗高級，而在學會和了解了Javafx之后更是幫助自己在裝飾和美化高級化代碼內容的路上越走越遠，甚至聯想到了可以利用javafx制作一些基礎的小游戲，說明這些作業是充分激發了自己對于代碼編寫的認知和興趣愛好的。還有對于各個領域的運用都有了自己獨特的理解，現在目前比較欠缺的就是運用極其稀少的封裝和集合框架，而javafx也只是停留在了解和最基礎的模仿階段。還是有許多要學習東西。

三：踩坑心得

學習Java，切記要思路清晰，在腦子里優先建立運行框架，拿起來直接編寫是大忌，極有可能走向繁雜無用耗時耗力的陷阱，哪怕是不寫類圖，也要有一個清晰的流程，等流程構建完畢和主體代碼具備之后在進行代碼功能的升級和修飾化。還有就是要善于利用AI工具和各種各樣的大佬帖子，在很多時候遇到無法解決的問題用眼睛瞪不是瞪不出來的，敢于去問，別人新的觀點可能就是解決問題的關鍵，這里推薦幾個好用的解題集合：CSDN，嗶哩嗶哩，豆包。

四：改進建議及總結：

這邊優先建議開啟實驗提交系統的復制粘貼模式，或者強化實驗提交系統的編寫代碼能力還有效果調節。窗口切來切去還要在密密麻麻的的同色字體之中找錯誤單詞真的有點麻煩。可能會導致學生編寫積極性下降，或者說時間上的損耗，如果說實驗提交系統是為了鍛煉打字速度，那確實是個不錯的選擇。但如果是對于知識的練習，那就設計的有點本末倒置了。至于課程和組織方式上倒是沒有太大問題，但是這邊建議給出超級大作業要求小組分工完成，提前讓學生們適應未來合作共贏式的工作模型，鍛煉合作和協調能力，畢竟學校不能保證每個學生都是獨狼。