OO第一次博客總結

OO第一次博客總結

　　大一就久仰OO大名。曾經有一份真摯的JAVA課放在個人面前，我沒有好好的珍惜，等到OO到來後，我才追悔莫及。人世間最痛苦的事莫過於此……如今來分析一下本身的代碼和心得，總結一下一個月來的收穫。

• 第一次做業

　　難點分析

　　第一次做業的要求是實現有必定魯棒性的多項式加減法，C語言代碼你們都練習過，所以算法部分其實並不是難點。對於大多數剛開始接觸JAVA語言和OO思想的同窗來講，此次的難點主要是：JAVA語法、面向對象思想、正則表達式的使用和程序的魯棒性。對於前二者，其實大一的python曾練習過面向對象的思想，但當要求寫一個面向對象的程序時，我眉頭一皺，發現事情並不簡單。看了不少遍課件，與不少的人討論，我也只是明白了什麼是一個「面向對象的格式」。回看這三次的做業，都存在着某個類150+行的現象，實際上仍是面向過程的。想理解怎麼寫纔是OO的，我推薦你們仍是要多看別人的代碼，可能初始階段會很艱難，好比我在第二次互測時拿到的代碼有23個類……可是若是堅持看懂，必定是頗有收穫的。正則表達式是一個便利的工具，但也存在必定問題，先按下不表。而程序的正確性以及如何保證不crash，就須要大量的測試驗證了。本身測得不夠全面，就極可能被別人看到代碼後，「量身定製」bug。

　　在設計上，我採用了一個Poly類型的數組Polylist來存放各個合法多項式，最後將數組的每一項和一個空多項式相加便可。坑在於如何判斷輸入時出現{（0，1），（0，1）}爲非法。該輸入係數均爲0，若將多項式係數初始值設爲0，將沒法判斷此輸入因指數重複而非法。解決辦法之一是對每一個指數開一個數組，存儲其是否被輸入過。然而更好的辦法是將係數初始值設爲輸入係數的上限，在最後相加時，對於係數爲上限的項不予相加。

 

　　類圖和度量分析

 

 

　　能夠看到，get_Poly方法的McCabe Cyclomatic Complexity和Nested Block Depth因超出範圍而標紅了。McCabe Cyclomatic Complexity（圈複雜度）用來衡量一個模塊的複雜程度，統計一個函數有多少個分支(if,while,for等)，沒有的話複雜度爲一，每增長一個分支複雜度加一。圈複雜度的做者McCabe認爲，圈複雜度在3~7爲比較好的結構化方法，圈複雜度大說明程序代碼可能質量低且難於測試和維護。Nested Block Depth（塊嵌套深度）則爲嵌套深度。這兩塊出現超標，每每說明程序設計有缺陷，或部分代碼嵌套深，難以判斷邏輯，或直接寫成了面向過程的思想。這個get_Poly方法內容以下：

 

 

 　　這個方法嵌套十分嚴重。除判斷錯誤輸入較多外，不只多餘的判斷了是否有異常字符，在切分多項式時，更是用了賊蠢的遍歷手動切分（手動切分也能夠寫的更簡單吧），切分後更是直接扔掉，待存儲多項式時候從新遍歷。其實第一次寫的時候，只用一個正則表達式匹配整個輸入，比上述代碼簡單太多，無奈測試時發現，當輸入過於複雜，正則表達式自身會引起crash，在判斷爲正則表達式自身的限制以後，無奈將匹配改成屢次匹配。代碼也所以長了許多，同時給debug產生了很大的難度，更是下降了代碼的可讀性，一層一層的嵌套着實使人難以讀懂。但這樣寫也有必定的優勢。頻繁判斷能保證錯誤輸入時儘快結束，防止惡意輸入時程序耗時過長（但實際上我判斷的確實過於頻繁了，增長了嵌套深度）。

 

　　測試分析

　　因測試較爲全面，並未出現bug。而我拿到的程序中，公測和互測的錯誤都是如未說明輸入「{}」的處理方式等Readme的錯誤。Readme做爲程序使用的指導說明，必定要考慮到全部邊界狀況，不然使用者僅根據本身的理解，極可能出現誤差。而事實上，程序出現bug，大多數時候也就是在這些邊界狀況上。在測試時，除了少許功能性測試外，大量的精力花在了特殊狀況、邊界狀況、超長輸入上（如一條大小爲1M的txt輸入數據）。

 

• 第二次做業

　　難點分析

　　傻瓜電梯的設計與驗證。傻瓜電梯的難點，應是對電梯的設計上，即如何實現電梯、分別給五個或者更多的類什麼功能、各個類之間如何串聯等問題上。我採用了三個double類型數組，分別存放ER、FR_UP、FR_DOWN每一層的按鈕燈熄滅時間，當指令輸入時間小於等於對應按鈕熄滅時間則斷定其同質。而電梯類elevator則存儲電梯在該指令執行完成後的時間、樓層、運動狀態，以供給調度器計算指令完成時間。對於指令隊列，從頭開始逐條取出處理。

 

　　類圖和度量分析

　　此次標紅的一樣是圈複雜度和塊嵌套深度，出現問題的方法除了和第一次做業相似的read模塊，用於識別合法性外，還多了一個schedule方法。這個方法僅僅用於輸出正確結果，但因當時考慮不周，分了指令爲ER、FR_UP、FR_DOWN和電梯爲運動或靜止，共6種狀況，過度冗餘，實際上一次就能夠說清。所以就不放代碼了，並不是難以改正的設計缺陷。可是能夠看到，floor類和其餘類並沒有鏈接，由於個人floor類是空的……設計上沒有用到floor類，也就使得其餘類的代碼行數開始增長。看似不影響，實際上給第三次埋了一個坑。雖然更加OO了一點，可是從類之間的鏈接數量就能夠發現，實際上仍是不清楚究竟什麼樣的代碼是面向過程的，從實質上來看，此次做業依然是OO殼子下的面向過程代碼。

 

　　測試分析

　　本次做業相較上次，輸入更加複雜，所以在功能性測試和邊界測試、壓力測試之外，加入了隨機生成輸入以進行測試。由於測試比較全面，一樣沒有bug，不過我拿到的代碼不只很是工程化，javadoc寫的也很是官方，23個類真的厲害……此處不作分析，類圖就不作整理了，搬運在下面了。也有同窗開始時使用時間做爲程序的條件，即每0.5秒取一次指令，這樣大大下降了程序的運行速度，恐怕更沒法經過10s的時間限制。

 

• 第三次做業

　　難點分析

　　ALS電梯。此次電梯的最大改進爲容許捎帶，這就出現了主指令和最多兩條捎帶指令（即若存在捎帶，能找到一條最早捎帶的指令，以及可能會找到一條和它僅指令標識符不一樣的指令一塊兒被捎帶）。所以排在後面的指令有可能被先完成，不能從隊列頭開始向後遍歷。我使用了一個指令隊列，規定頭指令爲主指令，判斷同質後，向後找最優捎帶指令，執行後從指令隊列中刪除。當全部比主指令先執行完的捎帶指令所有完成，執行主指令並從隊列刪除，將新的主指令置頂。循環下去至隊列爲空。然而在完成代碼的時候，沒有思考好捎帶的邊界條件和更新熄滅燈的時刻，使得判斷捎帶和同質時存在問題。此外，要求使用的繼承、接口、重寫也是新的難點。

 

　　類圖和度量分析

　　

　　對於圈複雜度和塊嵌套深度的問題，因爲基本沿用了第二次做業，不作贅述。慚愧的是，雖然要求使用繼承，因爲第二次做業中schedule沒有分到elevator和floor的部分，致使該類其實只有一個行爲，在子類中還被重寫了……實際並未用到繼承的思想。

 

　　測試分析

　　此次測試水平又進步了……經過兩個編譯生成的.class文件和隨機測試數據，能夠在python程序中實現自動運行和比對結果。本次的測試重點是捎帶請求和同質判斷。捎帶又存在功能性測試和開關門時的邊界測試。而同質則要考慮到新加入的捎帶請求是否爲同質，又是否利用捎帶請求信息更新了熄滅燈數組的時間。我本身就出現了判斷捎帶未注意邊界條件的狀況，也所以影響了燈熄滅數組的更新，使得判斷同質出現了問題。此外，兩次做業中schedule類明顯過長，成爲一個「萬能」的類，是不符合面向對象思想的。也致使了這個方法過於複雜，我通宵都沒能de完全部bug。

 

 

• 心得體會

　　關於設計和debug的體會，上文已敘。但經過讀手中拿到的代碼，讓我意識到了dalao的代碼水平是什麼樣的。但能讀到的代碼只有一份，對於你們理解面向對象思想十分有限，但願能在講做業的過程當中增長一下各類思路的介紹，能給你們帶來更快的進步。