oo到目前為止也算是結束了第一個階段，作為一個在本學期開學之前一行JAVA代碼也沒寫過的菜雞，這幾周過得真的很艱難。。。一切都是從零開始摸索，全靠查資料和翻書自學orz

在這次的課程總結中，因為電梯部分的作業更加困難，我出現的問題也較多，所以主要只對第二三次作業進行分析。

第二次作業——傻瓜電梯

一、程序分析

二、個人反思

　　拿到第二次作業之後，當時整個人是毫無頭緒的，本來是想通過畫出邏輯關系類圖先理清思路，但是冥思苦想了一個下午還是不太能理解課件所給出的的設計建議，於是決定按照自己的想法進行嘗試，由於不能理解樓層類的作用我最後只寫了四個類。我在基本梳理了一下整體設計關系之後開始寫代碼，剛開始寫得非常艱難，完全屬於寫了一行不知道下一行該寫什麽，從0到1很難，但是只要開始動手寫代碼，就像是一塊一塊地填補空缺的部分，從1到10就變得容易起來，由於傻瓜電梯相對比較簡單，DEBUG的過程還不算是太艱難。

　　最後的結果是公測和互測各掛了一個，原因分別是：由於對matcher.find( )的誤用，導致對輸入請求的格式分析出現了問題，對於輸入後面符合正則表達式、但左邊有非法字符的情況出現了錯誤判斷；另一個問題是由於scanner.close( )的使用錯誤，在只輸入”RUN”時發生程序崩潰，導致了一個crash錯誤。

第三次作業——ALS電梯

一、程序分析

二、個人反思

　　第三次作業是我完成得最糟糕的一次，由於開始時覺得只是在第二次作業的基礎上進行修改，可能比重新寫一個新的程序要輕松一些，態度就有些放松。研究指導書時，由於最開始對“捎帶”的定義理解的不是很清楚，於是決定先把大致框架寫出來，後期再進行詳細完善，這樣的想法很愚蠢。。。前期不完全的思考給我帶來了非常大的後期工作量，由於考慮的不完善，雖然開始時處理一些簡單的請求隊列沒有問題，但是一旦請求復雜起來，就錯誤頻出，最大的問題是：當捎帶隊列中有和主請求同樓層的請求時，應按照輸入順序輸出，但我的寫法是先處理捎帶請求，再最後處理主請求，這個問題的修改給我帶來的非常大的工作量，導致我捎帶處理的主體部分都進行了很大的改動，改動之後重新DEBUG也是一個非常費時的過程。我在DEBUG上花了這麽多時間主要還是因為對一些細枝末節的情況思考的不完善，不停地修改可能又會導致新的問題，這個過程的反復進行十分費時費力。

　　這次的作業雖然公測都通過了，不過互測被報了3個error和1個crash，當時看到被報了這麽多錯真的有點崩潰。。。雖然我的編程能力的確挺差的，但是看到辛苦寫了這麽久的作業被扣了這麽多分還是有點難過TAT 不過也應該感謝大佬給我發現了這麽多的錯（。crash錯誤還是上次只輸入”RUN”的問題，雖然上次被報錯之後進行了修改，修改之後本地運行情況看似是正常的，但是這次又被報錯之後我仔細分析了一下代碼，最後發現原因是我的程序在這種情況時無法關閉scanner，進程並沒有結束，仍可以在控制臺繼續輸入，本地運行雖然不會報錯，但是在oj上由於程序不能正常關閉，nextline沒有檢測到輸入，所以會報錯。第一個error是因為若下一條待處理請求發出時間大於當前時間時，當前時間應增加至與請求時間一樣再執行請求，這個點並不是沒有考慮到，而是因為思考得不夠全面在某些情況下出了問題；第二個error是因為我在輸出時將原請求時間的變量類型都強制轉換成了int型，若是輸入請求的時間過大則會發生錯誤；第三個錯誤是因為我在進行捎帶判斷預估請求到達時間時，是在當前時間的基礎上進行計算的，而沒有在請求發出時間的基礎上進行判斷。

　　在發現別人的問題方面，我一般是用為檢查自己程序編寫的測試樣例來檢查別人的問題，並通過對方的公測錯誤發現代碼編寫過程中的邏輯問題，從而發現新的問題，我在這方面做得比較差，以後要加以改進（畢竟我連自己的錯都發現不了還怎麽找出別人的錯。。。

　　這三次作業的完成情況雖然都差強人意，但是以我的水平來說也算是盡力了。在這些作業中反映出來很多問題，主要是編程過程不夠規範化，動手寫之前沒有把思路理清楚，導致寫的時候基本是想到哪寫到哪，代碼邏輯十分混亂，但是我覺得這個問題的原因主要是我編程能力太菜，一時半會也沒法解決，因為以我目前的水平只能走一步看一步，沒有辦法在寫代碼之前就把整個過程清楚規劃好，只能慢慢改正了。

　　第一階段已經過去，新的征程即將開始。。。

面向對象編程第一階段總結