OO學習第一階段總結
前言
雖然之前接觸過java，也寫過一些1000行左右的程序。可以說面向對象的思想和java的一些基本語法對我來說是沒有難度的，但是這學期的面向對象依然給了我一個下馬威。這幾次的作業每次都很讓我頭疼。因為不僅要保證針對正確的輸入要反饋出正確的輸出，還要把錯誤的輸入分辨出來。這樣一來，譬如正則表達式和異常處理等新知識和小細節的不熟悉就會讓每一次作業變成讓人頭疼的對象。
其實抽象出來，我們現在完成的三個小任務，每一個都可以抽象成三個步驟。
- 檢查輸入的字符串是不是滿足要求，如果不滿足要求則報錯；
- 對滿足要求的字符串，將我們所需的數據從裏面提取出來；
- 根據需求編寫算法，代入數據，輸出結果。
我將逐次分析我的三次作業失誤出現在哪個步驟。
第一次作業
度量結果
類圖
第一次作業的算法實現還是很簡單的，在沒有時間復雜度限制的情況下，計算的時候只需要遍歷兩個需要計算的多項式，把次數相同的項的系數相加減，然後去除系數為0的項。最後輸出得到的多項式就可以。那麽問題主要出現在第一個步驟。
因為我們的多項式輸入時以字符串的方式輸入，而且格式十分復雜，為了防止正則表達式匹配時爆棧。我只好采用分階段逐次匹配的模式。就是先看字符串是不是滿足最基本的幾個式子加減的形式。如果滿足，看進行加減的式子是不是滿足多項式的形式。如果滿足，看多項式的每一項是否滿足指導書中對系數項數的規定。只有這三個層次都滿足的情況下才能算作是滿足輸入的要求。而且在檢查格式的時候自然用到了多項式格式的劃分，下一步提取成分也就是自然而然的結果了。
我的問題主要出現在在分層次的過程中對格式的檢查不太熟練，包括正則和java的字符串函數，在這個過程中忙於拆東補西，產生了可觀的bug。而且第一次作業也對指導書的重要性認識不夠。忽略了指導書上明確提出需要滿足的要求，比如先導零和最多50項等等。
第二次作業
度量結果
類圖
第二次作業是我完成的最滿意的一次作業。讀指導書，寫偽代碼和算法，寫了滿滿兩張紙（可惜紙因為被我塗塗抹抹的太亂了給扔了。。。）。
由於細心的準備，一二三步驟我都完成的不錯。但是這次作業我犯了一個可以說是只有計算機系同學才會犯的錯誤。那就是大樓的層數是從一開始算的，但我在寫算法和敲代碼的過程中都很自然的認為大樓的層數是從零開始的，畢竟平時從零開始的時候太多了。然後是電梯的狀態轉移，我定義了一個Stage類用來表示電梯的狀態，然後用Stage的數組來保存電梯從一開始的狀態變化歷史。包括執行請求更新狀態和查詢某條請求是否無效，都通過對這個狀態數組的操作實現，雖然算法沒問題，由於自己的考慮不周到，在代碼實現的時候，在某些指令上下搜索狀態的情況下會產生數組越界錯誤。這個反映了我另一個薄弱的知識點，那就是對拋出異常方法掌握的不熟練。
順便說一句，第三次作業是我唯一一次在互測中找出別人bug來的作業，因為自己的基礎不怎麽好，分到的作業又幾乎都是AK了所有的公測點，所以互測找bug找的很辛苦。每次找bug的時候基本都是盡力去看別人的源代碼，然後嘗試有目的地去爆破錯誤。這一次的bug應該是對方對java中的大數類不熟練造成的。在判斷一個字符串是否是數字(4字節)的時候，我的思路是先判斷是不是整數，然後直接轉化成bigDecimal類與那個最大的數字4294967295進行比較。那位同學判斷整數之後，就開始先比較位數，然後在一位一位的開始與4294967295比較（常見的C語言風格），這樣就造成了有先導零的時候字符串位數大而產生的判斷失誤。bug+1！
第三次作業
類圖
這一次作業的失誤完全是第三步算法的失誤，在改正了第二次的可笑bug後，公測互測都沒有找出格式方面的bug。因為第三次作業幾乎繼承了第二次作業的絕大多數內容。所以我本想在第二次的基礎上進行修改，然後發現因為請求不一定按照發出請求的順序執行的特點幾乎和我的狀態數組更新的方法完全沖突，然後就是無休止的出bug改bug，作業量超出了我的預計，直到ddl也沒有完全改正，所以公測報了一堆bug。直到截至之後我才反應過來，不應該迷信繼承的方法，應該直接重新實現和第三次指導書兼容的調度方法。算是痛定思痛吧，截至這篇文章發表前，結合多線程的指導書，第三次的坑已經基本填完，期待下一次的表現。
反饋
希望助教或者其他大神能發一篇異常try-catch的教程，這方面自學看書看的迷迷糊糊的，幾乎不敢使用，只能靠if-else維持程序的正常運行。感覺並沒有發揮java這門語言的特性。如果能有這樣的教程的話，一定會點100個贊的。
OO學習第一階段總結