第一次做業是一個簡單的多項式計算,然而對於徹底沒有接觸過面向對象甚至java語言的我來講並不輕鬆。好在通過一個星期的惡補java語言,我最終仍是寫出來了一個假面向對象的多項式運算java程序。java
類圖: 正則表達式
由類圖能夠看出該程序結構簡單,Tuples類中只有一個將字符型的多項式轉化爲二維數組的方法,而全部對數據的處理和管理都在主類中進行。這兩個類共同處理公共的多項式數據,致使每一個類的職責不明確,不具備自包含性。好在每一個類中的方法的分工職責比較明確,沒有出現單個方法規模過大的問題。算法
Bug分析: 編程
此次程序惟一的bug在於正則表達式的一個小錯誤,數字位數上的限制不正確致使不輸入數字也能經過正則匹配。數組
這一次做業對面向對象的要求高了不少。先從類圖開始分析。數據結構
類圖:測試
大體思路以下:主類的三個方法依次爲讀入數據、檢查數據合法性以及報告錯誤;主類讀入數據以後調用Manage類,後者的process方法經過對下層的四個類的方法調用,對數據隊列進行處理並輸出。電梯類(Elevator)存有電梯運行狀態的屬性,和每層的請求狀況,以及查看、修改這些狀態和請求的方法;樓梯類(Floor)一樣存有每一層的請求狀況和查看、修改這些請求的方法;請求隊列類(RequestQueue)中惟一的屬性是請求隊列,類中有對隊列元素操做和檢查同質請求的方法。請求隊列中的每個元素都是請求類(Request)的實例,每一個請求擁有類型、樓層、方向、時間四個屬性和得到這些屬性的方法。設計
從類圖中能夠看出我最大的問題在於Manage類只有一個方法,而這個方法的用途包含了遍歷請求列表,處理電梯狀態等。其次我將計算電梯狀態和輸出電梯狀態放在了一個方法中。這些設計致使代碼耦合性過高,邏輯不清晰。同時第一次做業中暴露的問題仍然存在,類和類之間並不獨立。對象
從OO度量方面分析:blog
能夠看到在主類和請求隊列類中的塊嵌套深度偏大,還需注意減小嵌套深度。
Bug分析:
本次程序沒有功能性Bug,惟一的Bug出在忘了加#號的輸出錯誤。。。然而因爲類之間分工不明確,爲後續第三次做業買下了很大的隱患。
因爲第二次做業中類之間關聯太高,致使我在此次做業中吃盡了苦頭,不只將第二次的代碼大幅度更改,還使得邏輯更加混亂複雜。整體上來來講這一次程序很是糟糕,甚至在功能性上都存在必定問題。下面着重分析存在的一些問題。
類圖:
一樣先從類圖入手。此次存在的問題較多,不少也是在前兩次中就存在的問題:
從OO度量方面分析:
該圖說明了請求隊列類(RequestQueue)的圈複雜度太高,這也就意味着代碼難以測試維護,程序可能出現錯誤的概率很大。也印證了類圖分析中請求隊列類過於複雜的問題。要解決此問題,必須將類的分工明確細化,結構合理化,將部分對請求處理的方法轉移到其餘類中,而該類中只保留對隊列基本操做的方法。
Bug分析:
這一次做業出現了功能性Bug,在計算捎帶的表達式上出現致命問題,最後掛了五個有關捎帶測試分支。
通過這三次面向對象編程實踐,我對面向對象有了些具體的理解,但仍然不夠深刻。總的來講,有如下幾點值得注意:
一、在拿到任務以後,不要急於敲代碼、開始構建程序,這樣作只會使得程序面向過程、調理不清晰。在拿到指導書以後,首先要仔細閱讀。在對指導書的要求有了充分理解以後,再對整個程序的結構設計構思,用自頂向下的方法逐層分析須要哪些類,每一個類的做用是什麼。
二、將程序功能"均衡"分配給多個類。隨着程序不斷複雜,所須要的類和類的方法也在不斷增多,此時應避免出現某個類統管全局或者完成大部分功能,優秀的面向對象程序是類玉類之間相互協同完成任務。
三、千萬別拖到最後兩天才開始着手寫代碼,就算你以前構思再久,就算你熬夜再晚,Bug照樣滿天飛。sorry,Bug就是能夠隨心所欲。