OO第一次放縱劃掉放鬆

非常開心地迎來了oo第一次放鬆，當我準備安裝好外掛程式，做好圖，弄好資料就來寫部落格時，才發現第一步我就過不去了。

安裝amaterasuml

amateras是用來自動生成類圖的外掛程式。

教程：當我一切都按教程做了，理直氣壯地點開new ——> other，並沒有教程所說的class diagram，連個amateras的folder都沒有。我一度懷疑我eclipse重啟得不夠給力，多次restart甚至重啟電腦。

如果你也是這樣，試試我找到的偏方吧：

解決方法是：

1、開啟命令列，到當前eclipse的目錄下，輸入eclipse -clean，重新啟動eclipse，這樣eclipse就會加上新外掛程式了。

2、如果外掛程式不能公升效，則請將eclipse\configuration\org.eclipse.update目錄刪除後再啟動eclipse:)你可以在eclipse的選單"help"-->"about eclipse sdk"-->"feature details" 和"plug-in details"中看到新安裝的外掛程式。

然後你再看看new ——> other，就可以快樂地建立class diagram了。

安裝metrics

metrics是基於度量分析**的外掛程式。

教程：但是！，但是！在安裝之前，要確認一下自己的是eclipse3.x，如果你使用的是助教給的eclipse，是使用不了metrics的。所以還是去官網下個最新版本吧~

以上是一點安裝時遇上的坑，下面來分析自己的**。

**分析

第一次作業

度量分析

類圖

第二次作業

度量分析

類圖

第三次作業

度量分析

類圖

對於度量的分析

這裡對標紅的mccabe cyclomatic complexity和nested block depth進行分析。（標紅表示超出範圍）

mccabe cyclomatic complexity 表示圈複雜度，圈複雜度用來衡量乙個模組判定結構的複雜程度，圈複雜度大說明程式**可能質量低且難於測試和維護。第二和第三次作業造成圈複雜度過高的原因均為排程器類中的schedule()方法。個人判斷是我的**的schedule()方法承擔的職能過多，不僅要去除同質請求，還要選擇可捎帶請求，最後還要將請求排序形成可執行佇列，對同質請求和可捎帶請求的判斷使用了過多的if判斷語句，每個if判斷條件也並不單一，導致了schedule()方法的圈複雜度過高。

nested block depth表示巢狀塊深度，巢狀深度表示if或者for或者while迴圈巢狀的個數。這裡的巢狀塊深度過大同樣來自排程器類的schedule()方法。由於在形成可執行佇列的時候對同質請求和可捎帶請求同時做了判斷，導致了過多的if語句和while迴圈多層巢狀。

其實這兩特點在debug的時候已經能體會到了，過高的圈複雜度和巢狀塊深度使得debug並沒那麼好受。

自我評價

優點：總……總得寫出點優點吧。

1.對於請求的解析，我分為了兩個部分，一是請求類的自我判斷，二是電梯類和樓層類對請求內容的解析。另外，每個類的在程式中的職責劃分還是很清晰的。

沒有序號2了。

缺點：1.初次接觸物件導向程式設計，對於類的劃分總與現實分不開。想用電梯類和樓層類解析請求源於想模仿電梯和樓層向排程器發生請求，於是又給電梯類增加了乙個構造器。這樣一來似乎使得電梯功能過於複雜。實際上，應該增加乙個inpu_handler類來處理輸入資訊。

2.對於請求佇列中同質請求和可捎帶請求的判斷，我都置於排程器中，使得排程器過於臃腫，並且在判斷過程中又由於需要不斷為排程器增加屬性和方法，使得排程器越來越複雜。或許可以增加乙個類用於篩選請求佇列，再將可執行佇列傳給排程器。

3.能力不足，在設計的時候未能考慮到**的維護與可擴充套件性。於是從第二次到第三次作業的過渡中還是出了不少問題。

oo三次作業以來，在各個部分花的功夫可以說是debug的時間 >> 劃分類的時間 > 看指導書的時間 > 寫bug的時間 >> 0。對類的劃分仍然需要加以斟酌，使各個類的方法和屬性更加明確，平衡各個類的負擔。

有乙個很深刻的教訓就是，當覺得類的方法實現起來過於複雜過於長時，應該考慮一下是否讓它承擔了太多，而不是一味地在類中新增屬性和方法，寫的時候「算了，不管了，我就這樣寫」一時爽，等寫完之後看著自己醜陋的**和蹩腳的劃分，重構的念頭就開始萌生了，連提交的勇氣的沒有。

關於bug

自己程式的bug

1.第二次作業的程式被找出時間順序判斷不正確的bug。

測試樣例：

(er,1,0)
(er,5,100)
(er,1,0)
run

在寫**，不對，在寫bug的時候，很天真的把開始判斷時間順序是否不正確的起點設定為請求發生的時刻是否為0，而不是該請求之前是否有正確請求。

改正之前：

if(floor_req.gettime() != 0 && floor_req.gettime() < this.queue.get(this.queue.size()-1).time) 
catch
(throwable a)

嘻嘻，希望大家一起加油，乾乾乾乾幹！

OO第一次放縱劃掉放鬆

OO第一次總結

OO第一次部落格總結

放縱的一次

OO第一次放縱 劃掉 放鬆

OO第一次總結

OO第一次部落格總結

放縱的一次

相關推薦

OO第一次放縱劃掉放鬆