第一次作業：多項式運算 第一次作業是一個簡單的多項式計算，然而對於完全沒有接觸過面向對象甚至java語言的我來說並不輕鬆。好在經過一個星期的惡補java語言，我最終還是寫出來了一個假面向對象的多項式運算java程式。 類圖： 由類圖可以看出該程式結構簡單，Tuples類中只有一個將字元型的多項式轉化 ...
第一次作業：多項式運算
第一次作業是一個簡單的多項式計算，然而對於完全沒有接觸過面向對象甚至java語言的我來說並不輕鬆。好在經過一個星期的惡補java語言，我最終還是寫出來了一個假面向對象的多項式運算java程式。
類圖：
由類圖可以看出該程式結構簡單，Tuples類中只有一個將字元型的多項式轉化為二維數組的方法，而所有對數據的處理和管理都在主類中進行。這兩個類共同處理公共的多項式數據，導致每個類的職責不明確，不具有自包含性。好在每個類中的方法的分工職責比較明確，沒有出現單個方法規模過大的問題。
Bug分析：
這次程式唯一的bug在於正則表達式的一個小錯誤，數字位數上的限制不正確導致不輸入數字也能通過正則匹配。
第二次作業：單部電梯（FAFS策略）
這一次作業對面向對象的要求高了很多。先從類圖開始分析。
類圖：
大致思路如下：主類的三個方法依次為讀入數據、檢查數據合法性以及報告錯誤；主類讀入數據之後調用Manage類，後者的process方法通過對下層的四個類的方法調用，對數據隊列進行處理並輸出。電梯類（Elevator）存有電梯運行狀態的屬性，和每層的請求情況，以及查看、修改這些狀態和請求的方法；樓梯類（Floor）同樣存有每一層的請求情況和查看、修改這些請求的方法；請求隊列類（RequestQueue）中唯一的屬性是請求隊列，類中有對隊列元素操作和檢查同質請求的方法。請求隊列中的每一個元素都是請求類（Request）的實例，每個請求擁有類型、樓層、方向、時間四個屬性和獲得這些屬性的方法。
從類圖中可以看出我最大的問題在於Manage類只有一個方法，而這個方法的用途包含了遍歷請求列表，處理電梯狀態等。其次我將計算電梯狀態和輸出電梯狀態放在了一個方法中。這些設計導致代碼耦合性太高，邏輯不清晰。同時第一次作業中暴露的問題仍然存在，類和類之間並不獨立。
從OO度量方面分析：
可以看到在主類和請求隊列類中的塊嵌套深度偏大，還需註意減少嵌套深度。
Bug分析：
本次程式沒有功能性Bug，唯一的Bug出在忘了加#號的輸出錯誤。。。然而由於類之間分工不明確，為後續第三次作業買下了很大的隱患。
第三次作業：單部電梯（ALS策略）
由於第二次作業中類之間關聯過高，導致我在這次作業中吃盡了苦頭，不僅將第二次的代碼大幅度更改，還使得邏輯更加混亂複雜。總體上來來說這一次程式非常糟糕，甚至在功能性上都存在一定問題。下麵著重分析存在的一些問題。
類圖：
同樣先從類圖入手。這次存在的問題較多，很多也是在前兩次中就存在的問題：
- 類之間關聯性太大。ALS調度類不僅無法繼承原有調度類，更無法使用原來的其它類。很無奈我只能重新構造電梯類、樓層類，併在請求隊列類中增加了許多冗餘的方法來計算運動狀態。
- 具有相似邏輯的代碼段存在重覆。原先判斷同質請求的方法由於數據結構上的問題無法使用，無奈我又重新寫了一個方法兩者並用；執行主請求的方法和執行捎帶請求的方法上也有高度相似性，但是由於沒有設置參數區分主請求和捎帶請求，使兩種方法沒有能夠合併。
- 類的職責分工不明確。絕大部分工作都由請求隊列類完成，導致該類非常龐雜，也需要調用到很多其他的類和方法，整個結構看起來十分笨重，不利於維護和擴展。
從OO度量方面分析：
該圖說明瞭請求隊列類（RequestQueue）的圈複雜度過高，這也就意味著代碼難以測試維護，程式可能出現錯誤的幾率很大。也印證了類圖分析中請求隊列類過於複雜的問題。要解決此問題，必須將類的分工明確細化，結構合理化，將部分對請求處理的方法轉移到其他類中，而該類中只保留對隊列基本操作的方法。
Bug分析：
這一次作業出現了功能性Bug，在計算捎帶的表達式上出現致命問題，最後掛了五個有關捎帶測試分支。
互測心得
- 首先對程式的輸入進行分析，觀察代碼中存在的漏洞和邊界。
- 再對核心計算的代碼研讀，找到演算法中的邏輯問題。
- 最後看一下程式的數據結構，看一下是否存在結構不合理使得程式出現崩潰等問題。
- 能夠做到這三點都沒有錯誤的大佬，就已經是完整的設計了。
總結
經過這三次面向對象編程實踐，我對面向對象有了些具體的理解，但仍然不夠深入。總的來說，有以下幾點值得註意：
1、在拿到任務之後，不要急於敲代碼、開始構建程式，這樣做只會使得程式面向過程、調理不清晰。在拿到指導書之後，首先要仔細閱讀。在對指導書的要求有了充分理解之後，再對整個程式的結構設計構思，用自頂向下的方法逐層分析需要哪些類，每個類的作用是什麼。
2、將程式功能"均衡"分配給多個類。隨著程式不斷複雜，所需要的類和類的方法也在不斷增多，此時應避免出現某個類統管全局或者完成大部分功能，優秀的面向對象程式是類玉類之間相互協同完成任務。
3、千萬別拖到最後兩天才開始著手寫代碼，就算你之前構思再久，就算你熬夜再晚，Bug照樣滿天飛。sorry，Bug就是可以為所欲為。
