OO學習第一階段總結

前言

       雖然以前接觸過java，也寫過一些1000行左右的程序。能夠說面向對象的思想和java的一些基本語法對我來講是沒有難度的，可是這學期的面向對象依然給了我一個下馬威。這幾回的做業每次都很讓我頭疼。由於不只要保證針對正確的輸入要反饋出正確的輸出，還要把錯誤的輸入分辨出來。這樣一來，譬如正則表達式和異常處理等新知識和小細節的不熟悉就會讓每一次做業變成讓人頭疼的對象。

　　其實抽象出來，咱們如今完成的三個小任務，每個均可以抽象成三個步驟。

1. 檢查輸入的字符串是否是知足要求，若是不知足要求則報錯；
2. 對知足要求的字符串，將咱們所需的數據從裏面提取出來；
3. 根據需求編寫算法，代入數據，輸出結果。 

我將逐次分析個人三次做業失誤出如今哪一個步驟。

第一次做業

　　度量結果

　　類圖

　　第一次做業的算法實現仍是很簡單的，在沒有時間複雜度限制的狀況下，計算的時候只須要遍歷兩個須要計算的多項式，把次數相同的項的係數相加減，而後去除係數爲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個讚的。