一、三次面向對象 多項式計算： 第一次作業雖然只是練習簡單的字元串的匹配，但我需要從頭開始學習Java和麵向對象的思想。第一次面向對象寫代碼就會發現，難免又回到面向過程的思想上。我是先寫完Java再寫的C程式，雖然之後的C程式沒有用正則表達式，稍微有些冗長，卻感覺寫起來順手多了。這樣的不習慣反而讓我 ...
一、三次面向對象
多項式計算：
第一次作業雖然只是練習簡單的字元串的匹配，但我需要從頭開始學習Java和麵向對象的思想。第一次面向對象寫代碼就會發現，難免又回到面向過程的思想上。我是先寫完Java再寫的C程式，雖然之後的C程式沒有用正則表達式，稍微有些冗長，卻感覺寫起來順手多了。這樣的不習慣反而讓我發現自己已經慢慢接受面向對象了，雖然整體上還是有一些地方使用過程化思想寫的。這一次作業也讓我進一步瞭解了正則表達式便利，but本次作業唯一的一個bug也是因為正則表達式。
瞭解了正則表達式之後，有些偷懶地，就像直接一次性匹配所有的輸入，於是就輸入了一串長長的正則表達式。在自己測試的時候分別測了20個項和50個數對兩個邊界，卻沒有同時測20個項每個項都有50個數對的情況，所以並沒有發現自己的程式會因為迭代過深而沒能挺過壓力測試。這時候想插一句，try catch真是個好東西，雖然無腦try catch稍顯暴力，卻很有用。
第一次作業雖然花費了挺多時間，但代碼比較簡潔，複雜度也還可以。除了壓力測試，並沒有報出其他的bug。類圖如下：
從類圖可以看出，當時我對面向對象的理解並不是那麼深刻，我一直覺得一個類就能搞定這些事了，最後是為了創造對象而寫了一個Poly對象。從類圖上可以看出，Poly對象只是簡單地實現了多項式的加減以及最後輸出多項式，將與多項式有關的操作都寫到了這個類裡面。通過這次作業，我感覺面向對象和麵向過程比較顯著地差異就在於：面向對象你是對對象進行這個對象範圍所允許的操作，而面向過程是有一個公有的操作在那裡，你去調用就好了。按照這種邏輯，程式一旦變得複雜起來，面向對象會讓整個程式更加清晰，功能更加明確。
傻瓜電梯：
第二次作業開始寫電梯，實現起來並不是太困難，卻為第三次作業埋下了一個伏筆，能不能繼承成為了一個十分關鍵的因素。先從類圖看看我這次作業的實現：
基於Eclipse在寫程式的時候對類的調用是非常方便的，我用了一個類表示報錯，這是我通過閱讀上一次被分到的那個同學的代碼學習到的（原來我每次報錯都在程式中寫出）。ErrorReport類可以幫助我在第三次改了報錯情況的時候很快地修改，並且不至於遺忘躲在某個角落的報錯，導致最後會因為輸出格式的原因無味的掛掉一些測試點。
Elevator類和Floor類分別管理了電梯內部按鍵的情況和樓層按鍵的情況以及同效請求的分析。對於判斷同效請求我是通過三個數組（分別對應電梯內所有的樓層按鍵Elevator.button[11]，所有樓層的上行鍵Floor.upbutton[11]、所有樓層的下行鍵Floor.downbutton[11]）來對每個按鍵的作用時間進行記錄，如果之後的請求是在該按鍵作用時間內即被判定為無效請求。然後每個請求進行判斷後直接就加入到了Queue類中，而調度類非常雞肋，也導致了我第三次作業的工作量增大。而Requesting類裡面就是每個請求的一些特性，主要是記錄的作用。
最後公測掛了兩個點，竟然是因為在進行字元串判斷的時候我用了”==”而不是”.equals()”。當然我也不是故意這麼用的，而是在我其他的字元串判斷都沒問題的情況下，可能寫那一段是在我某個神志不清的時候，在寫十樓不能上一樓不能下的時候順手就用了”==”，而最後我測試的時候想當然覺得這裡應該不會出問題，就沒有測。歸根結底，還是——懶了一下。測我的那個人也非常仔細，找到了我在順序上犯的一點小錯誤。
程式的複雜度如下：
嵌套深度和複雜度都體現在Queue類裡面的addf()和adde()兩個函數上，它們的作用分別是在隊列裡面加入電梯類指令和樓層類指令。因為我把很多該指令是否有效的判斷裡面了，導致這個Queue類本身就十分複雜。在完成電梯後，其實我馬上就意識到了，有些判斷完全可以移到前面去，可是功能都實現，就不想在改整個代碼的結構了。然後，然後就害慘了第三次作業。
ALS電梯：
先看一看類圖簡單地意會一下吧。什麼？看不清？的確看不太清，不知道能不能點開看高清大圖。我可以說，主要功能段我幾乎從我的第二次作業繼承不下來，所以重寫了所有的Schedule類，而且這一個類十分冗長，debug能de到眼瞎的那種。增加了EWork這個介面，通過這個結合實現了兩個關於電梯和樓層判斷的類，簡單地說就是將之前那段冗長的判斷拿了出來單獨判斷。並且是在輸入RUN之後統一進行判斷，而第二次基本上就是RUN之前就判斷好了，等著輸入了RUN就輸出。第三次作業與第二次作業的主要區別就是這些。
接下來看一看複雜度：
迭代深度和複雜性還是一如既往地高，反映出了我一個非常明顯的毛病，喜歡把很多判斷擠在一起實現，其實完全可以放在其他類裡面。不僅增加了複雜度，還給我debug時帶來了很多麻煩。
二、BUG
1、我的bug
bug主要出在這幾個方面：壓力測試、”.equals()”的使用、以及對電梯調度策略的正確理解。
2、測別人的bug
三次被分到的都是大佬的作業，公測幾乎都是全過的，readme讀起來會讓人有一種舒服的感覺。說是測bug不是說是向他麽學習，讀他們的程式學到很多不一樣的實現，讀他們的readme也會感受到他們的考慮是多麼詳盡。唯一一個稍有瑕疵的是第一次的作業那個同學的那個同學正則表達式有bug，也被公測捕捉到了，所以我剩下的只是學習。
3、怎麼測bug
我一般會拿自己測過的數據先過一遍，然後讀一讀他的readme瞭解他和我不一樣的要求，然後再讀他的代碼，看他在實現的過程中有沒有什麼細節沒有考慮到，再針對找到的瑕疵構造數據。
三、心得體會
·程式的可繼承性，作為面向對象的一個優勢，不能光想著功能的實現，萬一哪天你又需要這個功能你還能把它移植走，我覺得這樣的類才比較有價值。
·開始寫程式之前對自己的程式的結構有一個良好的設計與認識非常重要，能減少寫代碼時浪費的時間，也有減少bug加成。
·在慢慢熟悉Java語言後，我覺得應該有意識地去瞭解一下比如介面、子類父類、繼承這些東西在這門語言里的意義，而不是指導書說了要用介面，就為了使用介面而去用，而是去瞭解一下它可能在工程量更大的項目中更有利於編程人員去重構與維護。
