OO第一次博客

做爲一個面向對象編程的小白，這三次做業對於我來講難度其實很是大。所幸，OO教務組合理地安排做業讓我這個小白也能逐漸接受這一切。

第一次做業分析：

 

    因爲是首次使用Java語言編寫面向對象程序，所以本次做業寫得並不理想。事實上，也正是由於第一次的緣由，致使個人代碼充滿了面向過程的感受，並無很好的將表達式類的屬性進行封裝。於是在DEBUG階段形成了很大的麻煩。

    縱觀第一次做業，主要的bug出如今兩個地方：其一，使用正則表達式時，沒有考慮當輸入的表達式過長時，致使爆棧，從而使得程序crash。其二，未能準確理解指導書中對數字範圍的定義。從這兩點讓我意識到仔細閱讀理解指導書的重要意義。

第二次做業分析：

 

 

    在有了第一次的開發經驗以後，第二次的做業便好了許多。因爲指導書已經對每個類以及其屬性都說明的很清楚，所以這次開發的難度並非很高。惟一須要注意的一點就是當請求隊列非空的時候，須要判斷先後的請求發起時間來肯定新的請求是否可以入隊，不然會出現錯誤。

第三次做業分析：

    第三次做業是在第二次做業的傻瓜調度上新增了「捎帶」的功能。因爲捎帶功能的出現，每進行一次捎帶，會使得電梯運行的時間增長，於是會致使新的同質請求出現。個人程序只考慮到了本來的同質請求，沒有考慮因爲「捎帶」而致使電梯運行的時間，從而使得本來在傻瓜調度的電梯系統中非同質的請求變爲了新的同質請求，這使得個人程序出現了錯誤。在算法的設計上，我應該改成每次將主請求及其捎帶入隊以後，計算運行時間，而且根據這個運行時間，將本來的請求隊列遍歷，刪除新出現的同質請求，這樣才能保證運行完主請求後，不會出現新的同質請求。

    關於測試樣例方面，個人測試樣例是主要針對於邊界狀況的測試。我我的認爲通常能正確跑出結果的程序，通常的測試樣例都能正確，所以主要針對邊界狀況進行測試便可。

    不知不覺已經作完3次OO的做業了，能夠說，這幾回做業絕對是「拖延症」患者的噩夢。若是像從前面對計組那樣，總將做業拖到deadline前一天才開始動工的話，絕對是自討苦吃的行爲。每次拿到指導書的時候，我認爲有必要花費一成天的時間仔細思考這次任務的要求，規劃設計方案，明確每一個類的屬性以及方法。若是一開始便可以合理設計每一個類及其方法，那麼出現bug的時候，便可以很快地找到bug出現的緣由而且進行修改。

    OO之旅已然過去四分之一，望諸君且行且珍惜，切莫放棄！