OO第一次博客做業

寫在前面

倘若有的同窗在安裝metrics插件時遇到了下載斷開等困難

CHH同窗爲我提供了以下解決方法：

能夠從這裏下載壓縮包https://pan.baidu.com/s/110Paad1AlbG6xMRa1FVnRg

解壓後將兩個文件夾複製粘貼到eclipse安裝路徑進行替換

而後在package explorer視圖右鍵項目文件夾選擇properties把metrics打上勾就可使用了

第一次做業

1、度量分析

　　經過分析metrics圖能夠發現本身在方法set_Poly()上的圈複雜度太高，塊嵌套也太高，也就是裏面還有太多且過深的條件判斷語句。主要是由於在第一次程序設計時貪圖省事直接複製了C語言寫好的代碼，這個方法主要是將格式正確的字符串轉換成各項信息，可是因爲使用的是逐個字符讀取，其中的條件判斷格外多，尤爲是在所輸入的多項式複雜時，這個方法效率極低，設計時沒有考慮到，如今回過頭來反思以爲這個問題能夠被更好解決，例如使用split分割每一個項再利用parseint等方法就能夠輕鬆獲得所需信息，這一點上確實考慮不周，徒增了過多代碼。同時這一點也但願能給予同窗們警示，在條件判斷時建議仔細思考哪些是必要的，哪些是能夠簡化的。大段嵌套的if-else語句只會增長後期閱讀修改debug的難度。

2、類圖

　　在類的設計上我此次設計的比較簡單。Reader類用來讀取並初步處理字符串，讀入並剔除格式錯誤的字符串。Poly類僅用來存儲每一個項的信息並擁有計算方法。ComputePoly類做爲主類負責調用其餘類，耦合度較低，獨立性較高，設計還算簡練。

3、BUG方面

　　第一次的程序被查出了一個bug，是由於我在設計上犯了錯誤，當時考慮到輸入最多隻能爲999999，爲了標記那些項已經被記錄過，將每一個項的係數都設爲了1000000，這樣就能夠避免輸入相同{(0,5),(0,5)}這種階重複的狀況，原本應當在計算是忽略係數是1000000的項，結果我卻寫在了輸出時判斷，致使對於{(1,7)}+{(999999,7)}這種計算我並不會輸出階爲7的項，是很低級的錯誤，說明在編寫代碼的過程當中，切記想一出是一出，局部解決問題是不夠的，要考慮到特殊樣例，以及在全局應用上會不會出現問題。

　　在查別人bug的時候主要應用的策略是針對指導書創造小樣例，對於指導書中每個小條件獨立的測試，利用這個方法我查到了被測人兩個bug，分別是多項式和項個數超標的問題。個人被測人代碼偏向面對過程，是一個利用了有限狀態機的讀入程序，基本上就是一個主函數到底，雖然在功能上沒有問題，可是仍是以爲這個課程儘可能採用面向對象的思想。閱讀代碼後沒有發現別的什麼問題。測了幾組隨機大樣例也沒有發現問題便做罷。

第二次做業

1、度量分析

　　此次的metrics圖就比第一次做業看起來舒服一些，經過回去閱讀所寫的代碼我發現，致使此次程序複雜度下降的緣由主要是經過閱讀指導書和上課時老師講授的ppt，合理規劃了一個電梯程序所須要的各個類，將所作的工做進行分配和規劃，不讓某一個類負擔不該屬於本身的工做，也不要讓其中的某一項工做太重。

2、類圖

　　我認爲本次的類設計上比較符合要求，經過scheduler類來調度elevator從請求隊列取出請求進行處理，可是本次設計上仍然存在問題。

一、爲了儘量貼近面向對象的思想，我把請求的提出方法分別在電梯和樓層類中定義，企圖用這種方法讓請求更像是電梯或樓層提出的，可是這致使了兩個類中一部分代碼的重複，代碼複用性很差，後來再看也以爲這種設計比較累贅。

二、請求隊列的實現上原本想使用arraylist，可是在編寫前想到本身對arraylist的方法瞭解很少，徹底能夠經過數組和定義相關方法來本身實現，方法比較少能夠下降錯誤率，這一點上其實我也說不清楚究竟是好是壞，可是在代碼行數上的確有了增長。

　　經過類圖能夠發現，此次設計各個類分工還算明確，可是在方法上定義過多，不該該爲每一個類的內部屬性都定義get-set方法，要考慮到程序的應用狀況。

3、BUG方面

　　此次做業並無被查出bug，可是並不表明本次做業沒有問題，第一個是前文提到的在某些類上設計過於臃腫，第二個是我是使用了部分try-catch，這個若是測試者本身觀察是能夠發現的，可是因爲沒有套try-catch的部分並不能想出來什麼崩潰的可能，可是爲了以防萬一，建議你們在設計上仍然要考慮周全。

　　在測試別人程序時，仍然使用了各個狀況單獨測小樣例，而後跑隨機大樣例的方法，被測人的程序寫的也的確很優美，閱讀代碼後發現吸收了其去除同質請求的方法，經過預測結束時間，掃描隊列直接去除後面的請求，而我使用的是記錄每一個按鍵的滅燈時間，在讀取到請求是進行比對，變相的空間換時間，可是須要實時更新時間，而且在後面的做業上處理捎帶有些麻煩，因此在後面進行了更改，經過比對互相的代碼體會實現功能的不一樣方法，這個能夠說是我從別人代碼中獲取最大的收穫。

第三次做業

1、度量分析

　　經過分析metrics圖能夠發現，在學會使用本工具前，筆者仍然存在着圈複雜度太高，塊嵌套過深的問題，在之後的編程過程當中會多加註意。第三次做業中主要編程不合理的是command()方法，原本設計是想利用這個額方法處理請求，可是順着思路寫的時候把輸出結果寫在這一個方法裏面了，甚至包括了輸出的排序（在同時完成多個請求的狀況下），致使使用了過多的if-else判斷和嵌套，如今反思應當單獨編寫輸出方法，經過傳參數來輸出不一樣結果，將這部分分離出來，下降圈複雜度，應當會使代碼結構好不少。至於塊嵌套深度部分，請求隊列類中因爲是本身編寫的add()方法，因此在實現上用了比較多的if-else，將會在下次做業中改寫爲arraylist，一樣的問題也在一個名爲findbest()方法中，這個在設計時是爲了尋找到主請求路徑上最好的捎帶進行執行，代碼編寫時條件能夠進行合併和縮減，當時並無考慮到，通過度量分析就很明晰的顯示出來了，這也給了我一個啓示，條件判斷不光要思路清晰明確，也要考慮嵌套深度和比較次數，不然代碼冗長囉嗦，不易修改和閱讀。

2、類圖

 

　　本次的類圖相比較上次的主要是編寫了elevator接口，而且新寫了scheduler類進行了繼承和方法重寫，可是其餘的類基本沒有改變，因此上一次做業所存在的代碼複用性差，重複性高的問題依然存在。而且還有一個問題就是對toString()方法理解不到位，在最後才考慮着重寫這個方法，致使在該方法的使用上有一些爲了使用而使用的痕跡，這點應該在程序設計開端就進行考慮。

3、BUG方面

　　第三次做業並無查到bug或者被查到bug，使用的策略依然是單獨用小樣例測單個狀況，再使用大樣例跑程序和別人的結果利用python對拍，這裏主要是修改了被測人的代碼，跑了3w和5w條指令的程序，但願能以這種方式發現問題所在，而後再回歸程序尋找問題的具體緣由。在本身的debug過程當中一度陷入了心態崩了的狀況，一個樣例剛調好，更新的代碼又出現了新的問題，一個又一個的打補丁，這時候應該通讀一下本身的代碼邏輯，在邏輯沒有問題的狀況下再逐步檢查每一個方法的細節，結合單步調試和輸出調試，總能發現問題所在。

心得體會

一、首先是以爲本身的確在慢慢體會面向對象的過程當中，從程序設計開始，先思考須要什麼對象，他須要什麼功能，而我只須要一個框架，而後交給對象作就能夠了，這個過程我認爲在程序設計上有利於全局的審視整個程序的造成過程，一樣在遇到問題時也易於定位修改。

二、在調試程序的過程當中學會使用了eclipse的單步調試，在面對電梯的輸出時經常面對從某一行忽然就不同了，須要用單步調試查看各個變量的變化狀況，很容易就能定位到錯誤位置。同時結合輸出調試能夠更加快捷的debug。

三、寫程序必定不要着急，包括指導書的閱讀，好的理解和思路對於程序設計事半功倍。

四、初次接觸面向對象編程和java語言，須要學習的還不少，這幾回做業學習並實踐了正則表達式、接口、繼承、try-catch、this關鍵字、動態數組、對象相等和狀態相等的關係、屬性可視性（public、private、protected）等知識，但願能在以後的學習實踐中多多回顧應用。

五、一點小建議，博客的撰寫能否分紅幾回小的部分放置於每次做業以後，目前總結1-3次做業發現了不少共有的問題，想必更早的總結能爲後面的工做提供前車可鑑。

六、對本身的但願，可以在搭框架的過程當中思路更加明確，用好接口、繼承，要知道只有在實際中使用到了，這些特性纔算是有用的。