OO第一次博客總結

　第一次做業：　

度量圖：

 

　　雖說對oo這門課早有耳聞，但實際上只有本身上了才知道。因爲本身之前沒有學過java，也沒有面向對象的思惟。無奈，花了一天自學了java的基礎語法以及一些基本的編程規範。可是第一次做業的實戰就暴露出匆忙學習的後果。首先就是正則表達式的匹配識別，本身一開始的確想到了單個識別，即把每一個多項式拆開進行識別匹配，這的確是個不錯的方法，因此我並無遇到正則爆棧的狀況，可是我卻在如何分，以及分後識別出了問題，對Pattern和Matcher類不熟悉，致使程序並不能徹底識別全部非法輸入，在其後的公測互測中也體現出來了。此次做業給個人java編程入了個門，我充分吸收了教訓，並期待在下次做業不在重犯。

　　  第一次拿到別人的代碼，也不太會調試，看了看程序，跑了一下本身構造的數據，過了，而後仔分析別人的代碼至關簡潔，並且面向對象的思想十分清晰，我認真學習了大佬的代碼，決定用於下一次做業中。

第二次做業:

度量圖

類圖

　　此次做業對我來講仍不算輕鬆吧，雖然說有了上一次經驗，這一次寫起來倒不是很模糊，但此次的指導書是我第一次見到這麼長的，我花了好久閱讀指導書。由於明確要求實現五個類，個人思想就是電梯類負責電梯請求以及電梯的輸出，樓梯類負責樓梯請求，請求類負責是別兩個來源的請求是否合法，請求隊列則是專門存放合法請求，調度器類就是對請求隊列裏的請求進行調度輸出。

        此次做業，總體實現調度並不複雜，可是判斷同質仍是花了我好一番功夫，我用的笨辦法，就是把全部的合法請求的信息記錄下來，用for循環判斷是否有同質的請求，我在for循環裏從後往前找，可能節約了一部分時間吧。

      此次做業我犯了一個可能沒有人會犯的錯誤，由於指導書說不與實際電梯一致，我就只看了指導書的例子，沒有進行分析，我覺得只有STILL狀態才須要開關門一次，其餘的沒有考慮開關門的一秒。因爲這個問題致使公測直接錯了不少。

 

第三次做業：

度量圖

 

類圖

 

 

　　此次做業大抵是咋上一次上進行添加功能，聽起來簡單，可到了實際分析時才發現很是的複雜，捎帶的狀況當時沒有條理進行分析，致使代碼至關臃腫，但最後把大量重複代碼寫成函數後，把幾種捎帶合爲一體就簡化了許多。

個人大致思想就是遇到主請求後進行請求隊列掃描，把捎帶請求放到捎帶隊列裏，並刪除相應的請求，遇到電梯類的超過目標樓層的請求，則進行從新掃描，獲得請求隊列後，調用第二次的方法進行輸出便可。

        但在這裏我又很傻地犯了一個錯誤，有一個地方數組越界了，這是隻有數組長度爲1時纔會crash，不幸的是公測的非法判斷全是這種數據，因此本身一個也沒對，究其根本，仍是本身沒有進行充分測試，一些極小數據由於簡單而不測，這是很很差的思想。

由以上三次做業，我有如下幾點心得體會，與其說是分享給你們，不如說是告誡本身。

1，  不要拖拉，提早寫，由於真的事情愈來愈多

2，  認真讀題，仔細閱讀指導書，不要着急寫

3，  構造數據前，必定要看看bug樹，這會給我方向

4，  進行覆蓋測試，不管大小

5，  虛心學習別人的長處，體會Java面向對象編程的魅力