OO博客做業1：第1-3周做業總結

（1）基於度量來分析本身的程序結構

注：UML圖中每一個劃分了的圓角矩形表明一個類或接口，箭頭可表明建立、訪問數據等行爲。類的圖形內部分爲3個部分，從上到下依次是類的名稱、類包含的實例變量（屬性）、類實現的方法。接口圖形內部只分2個部分，上方爲接口名，下方爲接口定義的抽象方法。箭頭上的註釋進一步解釋了類之間的關係。

做業1：多項式運算

兩處紅色的問題都出自checkformat方法。該方法圈複雜度高，塊嵌套深度高。緣由在於本身的格式檢查沒有使用推薦的正則表達式，依然使用了傳統的有限狀態機。這就容易形成邏輯複雜、代碼過長。並且，該方法完成的功能已經不侷限於格式檢查，而包含了信息提取的代碼，同時實例化了term, poly, compute類的對象。

 

第一次做業初步體現了面向對象思惟。主類的main方法只負責讀取輸入，以後建立了check類並將工做轉交給check。checkformat方法則有「全能」的問題，負責了格式檢查和輸入提取，同時建立了term, poly, compute3個類的對象。被提取的輸入會被整理爲term和poly對象。最終，建立compute類下的對象，計算並輸出結果。

做業2：單部傻瓜電梯

第二次做業較第一次有所改觀。大部分方法的規模控制在30行如下。最長的方法爲main，行數下降爲120行。main方法圈複雜度較高。

第二次做業的進步之處在於使用了正則表達式進行格式檢查，同時用String類下的split方法對有效輸入的各部分信息進行分離提取。存在的問題是main方法承擔了較多工做，一些沒法經過簡單檢查正則表達式就能識別的錯誤仍須要在main方法中檢查並報錯。將這部分功能獨立出來會簡化main的邏輯。

因爲課件中已經給出了參考設計，並明確要求實現5個類，所以設計思路基本遵循了課件。不足之處在於調度器dispatcher對同質請求的判斷只經過了隊列先後請求信息，而沒有利用樓層、電梯按鈕信息，並未徹底符合老師的初衷。並且這種判斷方法也容易致使BUG出現。

做業3：單部ALS電梯

 

 問題比較嚴重的是main方法與schedule方法。main方法圈複雜度高，問題與第二次做業類似，都是把對無效請求的部分判斷邏輯放入了其中。schedule方法塊嵌套深度高，儘管將捎帶請求的判斷獨立寫了方法，可是針對電梯內請求的狀況提煉總結不夠，致使判斷語句嵌套深度高。

因爲樓層類沒有實現預約功能，且出現BUG，本次做業沒有將其實例化。對於繼承、多態相關的設計要求均予以實現。爲此，dispatcher的各方法作了較大的調整。

總結：

本身在整體設計上的優勢是盡力按照面向對象的思惟進行整體設計和編程，讓各個對象管理本身的數據，減小數據傳輸，功能合理分散。沒有出現本身互測拿到的那種一個方法分擔了90%左右工做的狀況。

缺點在於在拿到做業之初，通常不會進行書面的整體設計，致使常常性的代碼改動，甚至推倒重來，在大規模開發中不可取。

一些細節並無徹底遵循指導書的意思，致使後續做業的工做量增長。（第二次做業的schedule方法就是一個例子）

第3次做業的樓層類屬於雞肋，沒有被實例化過，這種作法儘管在同窗中比較廣泛，並且我也拿到過這樣的代碼，可是很不可取。

個別方法的判斷邏輯過於複雜，判斷和循環嵌套較深。具體的方法、類上文已詳細指出。

 

（2）分析本身程序的BUG

第1周做業：

BUG1：空多項式輸出{(0,0)}，指導書要求只輸出0

BUG2：同一個多項式的項之間不檢查是否缺失和多逗號

BUG3：多項式之間運算符缺失不報錯，按加法處理。

分析：

BUG主要是格式檢查不仔細、輸出格式與指導書不符。問題所在的類是check，方法是checkformat。

checkformat方法沒有使用推薦的正則表達式，依然使用了「計算機組成」課中學習和使用過的有限狀態機。實現有限狀態機的代碼邏輯會比較複雜，其可靠性很大程度上取決於編程者在繪製狀態轉移圖時可否不重不漏、邏輯縝密。一旦需求變動或發現BUG，代碼的修改也是一個很困難、痛苦的過程。本身設計時擅自簡化了一部分邏輯，而且沒有辨析哪些屬於指導書硬性要求，致使產生BUG。

分類樹分析：

BUG更多發生在「輸入格式不符合規定」分支上，這與以前的總結相吻合。

 

第2周做業：

BUG1：格式檢查不支持前導零、正號。

BUG2：輸入樓層爲0時程序crash

BUG3：時間爲很大的整數時計算出錯，時間越界不報錯

BUG4：樓層類數組實現邏輯出錯，在特定樣例下crash

BUG5：同質請求判斷不許確

分析：錯誤種類包括格式檢查出錯、同質請求邏輯不正確。出錯類和方法包括：

類名	方法名	功能
strprocess	checkformat	輸入字符串格式檢查
floor	全部	樓層號和上行、下行按鈕
dispatcher	check2	同質請求的判斷

在設計樓層類時，不明確這個類的真正做用，設計了上下行按鈕卻沒有將其歸入判斷邏輯，並且數組的基本知識掌握不牢固，發生了數組越界異常的慘劇。因而第3周的做業乾脆取締了這個類，儘管可能與老師的軟性設計要求相違背，可是客觀上提升了程序的可靠性。

分類樹分析：

「數字範圍測試」被發現的BUG居多。主要是忽略了樓層爲0的狀況、對時間沒有設上限。

 

第3周做業：

BUG1：沒有實現多個同層捎帶請求只開關一次門

BUG2：主請求選擇錯誤

BUG3：同質請求判斷出錯

分析：BUG出如今本次做業的重難點——捎帶與主請求選擇上。

類名	方法名	功能
als	schedule	ALS策略調度電梯
als	judge_f	判斷樓層請求可否被捎帶
als	jucge_e	判斷電梯請求可否被捎帶

分類樹分析：

「合法輸入-正常狀況測試-多個捎帶」被發現的BUG居多。本身對代碼邏輯擅自簡化，沒有嚴格實現指導書中關於多個請求捎帶的要求。

 

（3）分析本身發現別人程序BUG所採用的策略

策略1：閱讀理解正則表達式

對用戶輸入進行格式檢查是這3次做業的共性問題。錯誤分類樹在格式錯誤上也設置了很多的扣分點。筆者3次抽到的代碼都是利用正則表達式完成的格式檢查，所以要想發現對方格式檢查方面的錯誤，檢查正則表達式是最佳突破口。

策略2：明確硬性設計要求

爲了強化學生對於面向對象思想的理解，每週的做業都會提出一些設計要求：第1次要求使用數組。第2次要求必須實現規定的5個類，不容許出現public的屬性。第3次要求必須實現接口，重寫和重載指定的方法。本身寫代碼時就要看清這些要求，同時拿到互測代碼後也要嚴格檢查。利用eclipse的outline窗口可以看到類、實例變量和方法，理清被測代碼的設計結構，方便對設計要求的檢查。

 

（4）心得體會

1）急於完成做業，沒磨刀最後誤了砍柴工

每週的做業一發布，本身就着急忙慌地打開IDE敲代碼。卻不知在寫程序前沒有對整體開發作出明確規劃的話，每每會頻繁改變本身的設計，補上本應在寫代碼前作的功課。本身的狀態常常是週末寫寫停停，而後在週日的下午將一切推倒重來，最終在週一的晚上完成了一個基礎性的設計，經過了正常功能的測試樣例。週二針對答疑羣和Issue上的樣例測試本身的代碼，發現能修的BUG就修掉。週三則寫其餘課做業或望着IDE發呆。其實前幾回做業的時間徹底來得及，在開始開發以前把各個類的實例變量、方法想清楚，打好草稿是更值得推薦的作法。《Head First Java》甚至推薦學習者先寫僞碼和測試碼，最後再寫正常的程序代碼。這也是「磨刀不誤砍柴工」思想的一種體現。

2）整體設計要嚴格遵照指導書，不得偷工減料

「顧客就是上帝」的俗語在編程領域同樣適用。指導書提出的要求，做爲學生就應該堅定貫徹落實。若是偷工減料，最後吃虧的、學不到本事的仍是本身。第二次做業對調度器類給出了更加詳細的設計方案，包括command和schedule兩個方法，而我沒有實現。結果第三次要求繼承上次的調度器並重寫父類schedule方法的硬性要求害的我把整個類都重寫了。第三次要求將可捎帶請求放入集合，我改爲碰見一條執行一條，最後同層只開一次門的問題未能完美解決。

3）debug只有進行時沒有完成時

要問我每週三是怎樣度過的，個人回答竟是如此頹廢：盯着電腦屏幕度過的。一種多是發現不了bug在哪裏，想到什麼測什麼，或者直接從微信答疑羣和Issue上借用別人的數據。一種多是bug太難修復，本身直接就放棄了治療。這不是一個二十出頭的年輕人應該有的狀態。一方面，只要提交窗口沒關，就還有補救的機會。發現bug就要積極去修復，而不是讓畏難情緒作了本身的主。第3次做業針對BUG在週三奮戰了一天，儘管最後沒提交那個版本，可是這種精神值得帶到後續的開發中。另外一方面，程序都有出錯的可能。自我測試期間對於同一個分支節點應該打破思惟定勢，多換幾組樣例，而不是過了一組就認爲絕對不存在問題。例如第二次做業樓層爲0致使crash和整數超長應報錯卻不報的問題徹底是多換幾組樣例就能發現的問題，卻在個人眼皮子底下溜走。栽了一次跟斗後總算認識到了自測的重要意義。

4）好逸惡勞思想做祟，倉促應戰

輔導員早已屢次強調過這門課程的難度非同小可，可是我卻一直以「大二下學期還早」的假象欺騙本身。《Head First Java》雖然早就買了，可是直到假期最後一星期才拆開塑封，直到開學前都沒有跑過一個本身寫的java程序。看到第一次做業的題目後，我嚇得頭皮發麻、直冒冷汗，由於本身已經有半年沒有好好寫太高級語言程序了。（計組實驗寫的是HDL語言）並且我發現本身一週看下來的java語法知識連應付此次做業都未入流。因而我次日卸載了全部手機遊戲，中止了一切娛樂活動，並作好了熬夜奮戰的準備。「臨陣磨槍，不亮也光。」我最終仍是在ddl以前完成了能經過大多數正常功能樣例的程序。可是此次的教訓值得吸收。假如我能在假期就將本身的電腦配置好java環境、把第五、6章的程序本身寫一遍、跑一遍，那麼第一次做業來臨時絕對會比如今沉穩不少。

5）學會使用搜索引擎

計算機專業的一大特色，在於書本不會教給你一切。《Head First Java》等參考書是爲學習Java語言設計的，並非Java百科。事實上，真正的百科不在書本里，而在網絡上。想實現一個功能而又在書中找不到相關知識時，不妨搜索一下，也許有的人早就爲此撰寫過一篇博客。