【面向對象設計與構造】第一次博客作業

---

一、程序結構分析

1. 第一次作業

類圖

由于第一次作業難度較低，實現起來也不需要很復雜的算法，因此在編寫程序的時候只建立了兩個類，Main類主要負責多項式的讀入以及對于輸入格式的判斷，Poly類則用數組對多項式進行存儲和執行整個計算過程，其中Poly類的compute方法執行了整個計算過程。

度量分析

Poly類的compute方法的代碼質量較低，顯得比較臃腫，從度量分析圖中也可以看出該方法的圈復雜度過高，容易出錯。由于之前沒有接觸過面向對象編程的思維和方法，所以程序的實現基本是按照面向過程的方法實現的，缺乏可擴展性。例如，如果要在多項式加減法的基礎上增加對多項式乘法的支持，那么整個Poly就要推倒重來，基本沒有可繼承的方法和屬性。

2. 第二次作業

類圖

第二次作業是實現一個簡單的電梯調度系統。在編程之前根據要求對五個類的功能和要實現的方法進行了規劃，請求類(Request)負責判斷請求是否有效，然后發出請求，請求隊列(RequestQueue)通過構造一個隊列來管理請求，樓層類(Floor)負責發出樓層請求，電梯類(Elevator)發出電梯內請求，記錄不同時刻電梯所在樓層，調度類(Schedule)負責調度電梯運行，Main類為主程序入口，統籌全局。由于程序結構的設計，Floor類實現的功能很少，與其他類的關聯程度也較低。

度量分析

這次作業每個類的代碼都比較簡潔，只有在Request類中負責檢查輸入格式是否正確的方法比較寫得復雜，代碼復雜度較高，在寫第三次作業時對這兩個方法進行了簡化并合并為一個方法。

3. 第三次作業

類圖

第三次作業在第二次作業的基礎上增加了捎帶功能，核心部分為ALS_Scheduler類對第二次作業中的Schedule類的繼承。由于調度策略的不同，子類重寫了父類的work()方法，繼承了檢查同質請求的方法checkSameRequest()，并增加了對于可捎帶請求進行檢測的方法checkPiggybacking()。另外，Elevator類實現了ElevatorInterface接口中的所有方法，并重載了toString()方法，用于輸出結果時調用。

度量分析

由度量分析圖可以看出，Request類中實現格式檢查的方法checkFormat()盡管在第二次作業的基礎上進行了簡化，復雜度依然較高。另外，由于增加了捎帶請求，不僅要在主請求執行時每到一層就要檢測是否有可捎帶請求，在每一條請求執行完畢時也要輸出它的所有同質請求，主請求執行完畢后還要循環判斷是否有同質請求可升級為主請求，所以導致work()方法內嵌套過深，這是在今后編程中需要改進的地方。

二、程序bug分析

1. 第一次作業

在第一次作業中，由于輸入的多項式格式較為復雜，如果直接利用正則表達式對輸入進行匹配，在輸入數據過多時就會導致溢出，因此我采用了先根據'}'對輸入字符串進行分割，然后對每一部分進行正則表達式匹配，但在編寫程序時忽略了多個 '}' 連續的情況，在最后的測試階段才發現了這個問題。

2. 第二次作業

第二次作業在程序功能方面并未發現明顯的bug，但是由于對于助教所補充規定的“必須輸出前100條請求的結果”這一句話理解不到位，在輸入超過程序指定范圍且未輸入“RUN”時直接結束程序，因此被互測者找到漏洞，可見我們互測時對于程序各方面的要求都非常嚴格，不僅要通過所有正常的功能性測試點，更要在一些細枝末節的地方下大量的功夫。

3. 第三次作業

第三次作業雖然只是在第二次作業的基礎上增加了“捎帶”功能，但實現起來卻要比第二次作業復雜很多。對于可捎帶請求的判斷，在指導書中是按照請求發出時間作為基準，但這種判斷方式實現時要考慮的因素較多，需要考慮多個可捎帶請求同時執行等特殊情況，但如果我們轉變思路，在主請求運行的整個過程中，每到一個新的樓層就判斷是否有一條或多條可捎帶的請求需要被執行完畢，然后只開關門一次，這樣實現起來就比較簡潔。但起初在編寫程序時在細節方面還是存在一些問題，比如沒有考慮到電梯可能在請求未執行完畢時出現空閑情況，且在到達目標樓層時，主請求和捎帶請求沒有嚴格按照輸入的順序進行輸出等，在最后的自我測試階段才發現并完善了這些問題。

三、bug分析策略

在我測試自己和他人程序的時候主要采取的策略主要有以下幾點：首先是要結合Readme文檔認真讀代碼，分析代碼的結構，在此基礎上發現問題，然后對癥下藥，通過相應的測試樣例來進行驗證。這種方法雖然需要花費較多的精力，但是可以發現一些普通測試樣例難以發現的問題，具有很好的針對性。在測試其他同學的作業時，發現大多數同學在程序主要功能的實現上一般不存在問題，比較容易出錯的地方在于對于各種特殊輸入的檢測與處理，正則表達式的使用等，而這類問題是最適合通過讀代碼來發現的。其次是編寫自動測試腳本來對程序進行全方位的功能性測試，尤其是像第三次作業那樣可能出現bug的情況較多時，這種方法就顯得十分有效。最后是再次認真讀Readme文檔，針對作者在文檔中規定的各種特殊情況以及相應的處理方式在程序中進行一一驗證，發現可能存在的問題。

四、心得體會

通過這三次作業的練習，我獲得了很多收獲。首先，在面向對象編程的學習方面，每次作業雖然不需要特別復雜的算法，但對于我們面向對象編程思維和編程能力的訓練確有很大幫助。通過短短幾周的學習，我們已經能夠用java來實現簡單的面向對象程序，盡管現在寫出的程序可能存在許多問題，但對于我們今后的學習來說無疑具有十分重要的奠基作用。其次，通過每一次的互測，我看到了許多風格迥異的代碼。一方面，這些代碼就像一面鏡子，通過讀其他人的代碼，我可以從中學習到許多優點和長處，同時也能在對比之下發現自身在編寫代碼時存在許多問題和不良習慣；另一方面，我也充分認識到擁有一個良好的代碼風格的重要性，我們今后所寫的代碼注定要由許多其他人來閱讀和維護，所以決不能寫出只有自己才能讀的懂的代碼。最后，我認為我們的面向對象這門課程，不僅僅是訓練我們的編程能力，更重要的還是要訓練我們分析各種需求的能力。盡管每一次的指導書都存在許多不夠明確和完善的地方，但是一味的抱怨解決不了任何問題，如何在指導書的字里行間提煉真正的需求，才是我們每個人應該學習和提高的地方。

轉載于:https://www.cnblogs.com/David-Liu-/p/8717850.html

總結

以上是生活随笔為你收集整理的【面向对象设计与构造】第一次博客作业的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。