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

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

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

總結：

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

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