OO第四次做業-對前三次做業總結

第一次做業因爲直接沒怎麼學過java，全靠一星期速成，前幾天看了java的語法，可是由於光看沒有打代碼，學習效果並非特別好。由面向過程轉向面向對象，不是特別清楚該怎麼辦，雖然寫的是兩個類，但其實是one-for-all的方法，全部的計算和輸入輸出全寫在一個類裏面致使一個main方法裏嵌套多層判斷，層次很是亂。輸入根據指導書提示學習使用正則表達式來匹配。因爲剛開始學習，因此第一次做業只能匹配出正確形式的輸入。由於時間安排不合理，最後剩餘debug的時間很少，致使沒遇上提交的時間。第一次做業暴露了不少的問題，時間投入不夠，面向對象思想的轉變，正則表達式的學習，以及debug。

第二次做業是寫傻瓜式電梯，和第一次筆比較，此次做業更具體，根據指導書提供的設計框架，讓人更容易設計。由於此次做業的電梯調度比較簡單，因此，此次主要是的問題是電梯調度類和請求類，請求隊列類的關係。此次由於設計緣由，把處理同質請求和計算時間都放在了調度類，統一輸入，統一處理。僅在請求類裏對不合理請求處理。在最後的debug環節裏，發現本身的程序沒有輸出，最後de了半天才發現，以前用與存請求隊列的數組是本身設定的定長數組，致使後來數組越界，改完bug後終於能過測試樹的點了。在此次做業中，由於本身設計的緣由基本沒用上電梯類和樓層類，代碼比例很不平衡。到第三次做業才意識到這會對個人代碼產生很嚴重的影響。

第三次做業是對第二次的傻瓜式電梯作一些改進，主要是調度方法的改變，增長一個對捎帶請求的處理。此次做業是對第二次做業的延伸，須要用到接口的實現和繼承父類，以及對父類方法的重寫。這時，第二次做業中調度類過於冗餘的問題就體現出來了，電梯類和樓層類過於簡單，致使重寫捎帶請求和從新處理同質方法時改變代碼太麻煩，重寫以後不能運行，再debug後只能處理非同質的請求，同質請求後的正常捎帶請求沒法處理。 這時我對本身第二次做業不均衡的代碼分佈感到很煩惱，對調度類debug的過程讓人很難受。這些問題本均可以很好的避免，由於讀指導書的不認真，致使設計的隨意，以至一步步對代碼產生愈來愈嚴重的bug，不只是語法上的錯誤，更是設計邏輯上的問題。

總結：

三週的學習，讓我知道寫程序時設計合理的重要性，以及投入足夠時間的必要性。debug也只是按照公測的結果來找bug，或者在設計之初就分好本身的校對樹，但通常都沒公測來的全面。通過這三次做業，能明顯感受到每週都在提高，這個過程確實比較吃力，可能學習方法上有不合適的地方，更多的多是時間投入的不夠。會在以後的做業改正，提高設計的能力。