• 作業一

先放上程序的度量圖和程序的類圖

這一次作業之前，我對JAVA可以說還是零了解，零經驗。利用作業剛開始的前一兩天惡補JAVA，總算是寫出了自己第一個有價值的JAVA程序。回過頭來看這次作業的質量，的確不算很高。寫起代碼來腦子裏想得最多的還是C語言，很多思想還都停留在面向過程上。每一個類裏面的方法雖然不少，但是更多的是為了獲取類中的私有變量，真正實現類運行功能的方法很少。比如StringOp類中，GeneratePoly方法需要連續多層調用3個本類中的私有方法；在主類中，程序的執行也是依次進行各個類的初始化，各個類之間的關系也僅停留在訪問其他類的私有變量上，這種程序行為與面向對象程序並不相符。

在這次作業中我也發現，由於基本功的問題，JAVA中的很多高級功能我沒有能夠很好的利用，比如涉及到字符串轉換為數字時，我沒有使用已經定義好的方法，而是自己新寫了好多行，構造了一個方法；還有異常問題，由於不適應JAVA中的異常處理機制，我自己定義了一個異常類，用於接收各種運行中的異常，並根據相應的返回值輸出報錯信息。這些問題雖然對程序的功能沒有過大影響，但是使得整個程序多出了很多不必要的代碼，顯得十分臃腫。

由於這次作業整體邏輯比較清晰，自己也根據測試樹構造了很多組測試樣例，改掉了自己的一些筆誤，因此在公測和互測階段都沒有被找到bug。

在互測階段，我拿到的程序存在一些bug。這位同學的程序基本上完全沒有使用面向對象的方法，依舊使用面向過程的方式，只有一個主類，其中有多個方法，隨著程序的運行依次執行。仔細讀一讀他的代碼，發現他雖然錯了不少，但是基本上問題都是在指導書的閱讀問題，比如對於正負號的支持、前導零的支持等，其他方面沒有運行錯誤。這也給我提了醒，讓我在今後的幾次作業中，進一步重視指導書中的要求。

• 作業二

從度量圖裏面可以看到，這次作業的圈復雜度有些高。仔細分析這其實是可以預料的，電梯請求是否符合要求的幾乎判斷全部在Request中的一個方法內執行，導致這個方法的圈復雜度高達12。我在設計的時候感覺這些判斷的邏輯都相對簡單，而且彼此基本處於獨立狀態，就涉及到了一起。但是現在來看，還是把他們分開設計，將功能類似的判斷整合進一個方法，這樣在執行上也會顯得更加清晰，再需要額外的判斷條件時，也會更加容易。

這次作業我覺得我的一個顯著進步就是應用了很多JAVA庫方法。由於第一次互測分配系統的原因，我實際拿到了兩份代碼，除了那份有bug的以外，我還拿到了一個大佬的代碼。在我閱讀他代碼的時候，我學習到了他使用JAVA自帶的異常處理類返回異常。我把這一特性應用在了自己的作業中，使我這次作業對於輸入報錯與運行時報錯的處理代碼變得非常簡潔，覆蓋也更加全面。除此之外，我還嘗試了JAVA中ArrayList的使用，方法的重寫等特性。

由於這次作業，電梯的調度比較簡單，僅僅需要在依次執行各指令的基礎上，加上一些基本的同質指令判斷，我在寫代碼的時候也就偷了一點懶，沒有完全按照推薦的方法設計類和方法。這也就使得我的方法更像C語言中的函數，他們自身的功能並不是很明確，都需要配合其他方法才能實現。現在回想，我沒能很好的抓住這次作業的機會進一步加深我對面向對象的理解，算是一點遺憾吧。

這次作業難度較上次有一定的提升，但是主要的關註點仍然是在輸入上。我在這上面也花費了不少的時間，也改了一些bug。但是還是有一處對空格輸入的處理上出現了疏忽，被同學互測的時候挑了出來。我這次拿到的同學的代碼實現思路和我的有很大差別，它通過定義了很多功能分明類，比如比我多了樓層類、按鈕類等等，來實現程序的功能。這種方法如果單看這一次作業確實顯得稍微麻煩了一些，不過我從中也得到了啟發，也看到了他在類的定義中合理和一些可以繼續完善的地方。我也是通過閱讀代碼找到了他的程序和指導書要求不一致的問題。

• 作業三

從這次作業的類圖上就能明顯看出，我的整體設計思路和上一次幾乎沒有什麽變化，因此度量超標的問題也就可以預見了。同時之前也提到了，由於上一次作業沒能很好的利用面向對象的方法，而是寫了一個類似於面向過程的調度器，使得我這一次作業實現起來有不小的難度。一個很明顯的問題就是調度器類中，循環和條件判斷嵌套過多，這是一個典型的面向過程程序容易出現的問題。由於在上一次作業中，我並沒有把各個類的方法的作用分得很清楚，在本次作業中，有沒有足夠的時間讓我對代碼進行重構，因此這一次的調度方法，我只能按照面向過程的思想，在一個方法中進行大量的判斷、方法嵌套等工作，從而完成較為復雜的電梯調度工作。

這次作業代碼的復雜程度明顯高於上次，可能的輸入組合大大增加。我一開始對此也是十分茫然，不知道從何下手。我也曾嘗試過從一些看上去比較簡單的部分開始先寫一點代碼，但是隨著工作的推進發現往往這些部分和自己最初的構想並不完全一致，有些甚至會涉及到非常復雜的操作。在經歷了失敗後，我最終靜下心來，再仔細的思考程序的具體要求是什麽，怎麽這些要求分類，轉化為可以被程序執行的多個邏輯塊。這一過程的確是痛苦的，但是真正當自己想清楚之後，整個程序的處理也就變得相對簡單了，在編碼過程中僅需對一些細節進行優化，而不會出現方向上的錯誤。

這次作業由於邏輯的復雜，我的程序在剛開始的一段時間甚至都不能運行，在後期也作了多處bug的修改工作。這一次測試樣例的編寫工作也是十分消耗時間的，而且由於存在捎帶規則，各條指令的輸入順序與執行順序不再有明確的關系，而需要在運行中判斷，因此也增加了很多種不確定的情況。在測試階段，我的程序和我拿到的程序都沒有找到bug，能明顯感覺到，同學的代碼質量提高了不少。

• 心得體會

這三次作業，我的成長是顯而易見的。從語言能力上，我從JAVA零基礎，成長為能編一些簡單的JAVA程序；在面向對象思維上，雖然我對將它們應用與編程上還不夠熟悉，但至少算是入了門，有了一些基本了解。

通過前兩次作業同學的bug，我深切的體會到，在程序設計過程中，應當嚴格遵守一切基本要求。指導書就是程序設計的唯一標準，與標準不符再完美的設計也是無效的。自己辛辛苦苦工作的成果很有可能因為這些非常容易實現的基礎要求而前功盡棄。未來的幾次作業難度必然將會更大，要求也會更加復雜，仔細閱讀指導書一定是一項必不可少的工作。

結合第二次第三次作業的情況，其實我在第三次作業中遇到的種種困境，其實與我第二次作業的不完備有著密切的聯系。由於第二次的草率設計，使其擴展性很差，要加入新功能時涉及到很多的類和方法的變化，給設計增大了難度，甚至有一種在泥潭中越陷越深的感覺。這也給我將來的設計提了醒，不能忽略任何基本工作，一些在現在看起來復雜刻板的設計，在未來的程序擴展編程中可能會起到至關重要的連接作用。

同時，依照第三次作業的經驗，提前對程序進行規劃是十分必要的。隨著程序功能越來越復雜，僅在頭腦中模擬程序運行有時候顯得十分吃力，在必要的時候多寫寫畫畫對思路的整理十分必要。尤其是針對面向對象的程序，更需要提前總結程序的屬性，規劃好各個類與方法的功能，才能寫出合格的程序。

在debug上，我的經驗是一邊寫，一邊檢查，同時進行一些簡單的測試。在程序中難免出現輸入失誤的情況，只要不是邏輯上的錯誤，這些問題往往再掃一遍代碼就能快速發現。因此在寫完一個小的功能區間後，快速看一遍代碼，檢查有沒有明顯的語法錯誤，也就變得很有效。在邏輯復雜的部分，通過編寫一些簡單的測試語句，可以檢查出有沒有明顯的邏輯漏洞，這樣當程序出現bug時，可以著重檢查各個代碼塊之間邏輯問題，而不用過度糾結於一個代碼塊內部是否有bug。

以上就是這三次作業的一點小小的總結與體會，與大家分享。

oo第一次總結