面向對象三次做業的總結

第一次做業：

Metrics度量分析

博主第一次面向對象的java代碼分析：第一次做業的目的是由面向過程到面向對象過渡，瞭解二者之間的區別。因爲第一次寫面向對象的代碼，不免會有面向過程的習慣，正若有些同窗調侃道：僞裝面向對象。博主的第一次做業的代碼中也能明顯看到過程化編程的痕跡，好比關於輸入內容的處理，判斷與轉化，這部分功能我直接在main函數中用了過程化編程實現，沒有封裝成一個單獨的類，。其餘的功能的實現，我參考了老師ppt上給出的結構樣例及方法，所以看起來像面向對象。第一次做業我有11個bug,準確來講是兩個bug;第一個bug:正則表達式匹配時爆棧了，雖然寫代碼的時候知道有這個bug,可是無奈正則表達式不熟悉，並且寫了一天代碼沒吃飯餓暈了，不想寫了。另外10個bug,也就是第二個bug:輸入格式錯誤要輸出"ERROR",結果我有一個地方把"ERROR"寫成了"ERROE",碰巧那個地方在個人設計思路里是匹配較多格式錯誤的輸出，就莫名多了10個bug。Mtrics數據分析中標紅的部分應該深度分析方面有點問題，本人設計思路方面屬於比較求穩，面面俱到，寧肯重複，也不漏掉一種可能狀況，所以形成了循環和嵌套得比較多。接下來的兩次做業也是屬於循環嵌套比較多。分配給個人測試代碼是個大佬的，找不出錯誤；

博主第二次做業的java代碼分析：設計思路：先將全部的指令輸入進行處理，包括判斷，轉化，生成相應的電梯指令，並將生成的電梯指令加入到指令數組中，而後經過schedule類進行統一處理並輸出結果。因爲指導書的硬性要求，必需要有5個類，博主各個類的功能方法看起來也還算比較分佈均勻，固然，有了第一次做業的心得，我增長了一個Judge來專門處理輸入，判斷和轉換問題。第二次做業剛完成的時候判斷部分有些冗餘，重複代碼行比較多，刪減了大約100行，主要是思路不清，考慮不全。細看博主的代碼結構，能夠發現，方法中set,get方法佔了很大的比重，各個類的屬性雖然定義爲了private,但更改仍是主要在其餘類裏面進行，自閉性不強。因爲第二次做業考慮周到，所以第二次做業沒有bug,分配給個人測試代碼又是一個大佬的，沒找到bug.

博主第三次做業代碼分析：代碼思路和第二次的相同。先寫點內心體會吧，前兩次的指導書看完了基本就能有思路了，總體架構可以出來，須要作的就是一些細節方面的理解和補充，第三次的指導書我看一天還不知道怎麼動筆，而後是邊想邊寫。固然最後仍是勉強把架構搭起來了，相比於第二次的代碼，我第三次只改了兩個類，一個是電梯類，一個是添加了schedule的子類son。這兩個類是大象類，電梯類屬性多，set,get方法多，son類的run方法足足有300行，沒辦法，雖然醜點，總比寫不出要強點。電梯類冗餘主要是由於第二次做業的屬性定義不敢去更改（構造電梯有效指令的功能裏用到了原來的屬性，而電梯指令構造方法沒有作改動），只能定義更多的其餘屬性來記錄相關的狀態和標記；說實話，ALS電梯調度真的有點複雜，考慮到的狀況有限，到後來寫完了拿別人的數據一測就能發現很多bug,因此son的run方法裏面電梯調度方案增長了一些針對調試中發現的bug而作出的補丁代碼，顯得有些無序。因爲我測試代碼沒按照給出的分支樹構造，所以漏掉了要考慮的狀況，另外，發現的bug也並無所有調試出來，有一個bug我調試了改了整整一天也沒有改過來，看來是改不出了，主要是一個標誌物的值在某條不相干的指令執行後居然改變了，致使後來的指令判斷髮生錯誤，爲了下一次的多線程，我仍是得從新寫run方法。這一次個人代碼有兩個bug,一個是輸出順序沒徹底弄清楚，致使順序錯誤，第二個就是我改了一天都沒改出來的bug。感受第三次指導書仍是有點問題，對同質請求，知足捎帶條件的請求的舉例不夠多，大多數的狀況都得從issues和助教口中親口得到，或許是我我的的理解能力不行吧。另外，本人的設計思路比較傳統，因爲某條輸入時間靠前的指令居然可能被輸入時間靠後的指令所攜帶，因此我用了三層for循環，也是夠拼的，還好只須要處理100條指令，不然我都要考慮運行時間內能不能有結果。總之，就是個人設計方面應該改進並優化一下。我測的代碼仍是個大佬的，又是零錯誤（我要得負分了，笑哭.jpg）。麻煩下次給我一個有錯誤的代碼，最起碼別讓我負分。

心得體會：

1：不要把多個類寫在一個class裏面，調試起來會很痛苦（尤爲是像我這種只會System.out調試的人），代碼寫到1000行的時候，上下翻看都困難。

2：不要急着動手，想得越清楚，理解得越透徹，寫出的代碼結構更嚴謹，須要更改的地方就少。