【面向?qū)ο笤O(shè)計與構(gòu)造】第一次博客作業(yè)

---

一、程序結(jié)構(gòu)分析

1. 第一次作業(yè)

類圖

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

度量分析

Poly類的compute方法的代碼質(zhì)量較低，顯得比較臃腫，從度量分析圖中也可以看出該方法的圈復(fù)雜度過高，容易出錯。由于之前沒有接觸過面向?qū)ο缶幊痰乃季S和方法，所以程序的實現(xiàn)基本是按照面向過程的方法實現(xiàn)的，缺乏可擴(kuò)展性。例如，如果要在多項式加減法的基礎(chǔ)上增加對多項式乘法的支持，那么整個Poly就要推倒重來，基本沒有可繼承的方法和屬性。

2. 第二次作業(yè)

類圖

第二次作業(yè)是實現(xiàn)一個簡單的電梯調(diào)度系統(tǒng)。在編程之前根據(jù)要求對五個類的功能和要實現(xiàn)的方法進(jìn)行了規(guī)劃，請求類(Request)負(fù)責(zé)判斷請求是否有效，然后發(fā)出請求，請求隊列(RequestQueue)通過構(gòu)造一個隊列來管理請求，樓層類(Floor)負(fù)責(zé)發(fā)出樓層請求，電梯類(Elevator)發(fā)出電梯內(nèi)請求，記錄不同時刻電梯所在樓層，調(diào)度類(Schedule)負(fù)責(zé)調(diào)度電梯運行，Main類為主程序入口，統(tǒng)籌全局。由于程序結(jié)構(gòu)的設(shè)計，Floor類實現(xiàn)的功能很少，與其他類的關(guān)聯(lián)程度也較低。

度量分析

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

3. 第三次作業(yè)

類圖

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

度量分析

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

二、程序bug分析

1. 第一次作業(yè)

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

2. 第二次作業(yè)

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

3. 第三次作業(yè)

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

三、bug分析策略

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

四、心得體會

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

轉(zhuǎn)載于:https://www.cnblogs.com/David-Liu-/p/8717850.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。