OO第一次博客做業

第一次做業

度量圖：

類圖：

 

　　由度量圖能夠看出，因爲在完成第一次做業時，不熟悉java，也沒有較好的理解面向對象式變成的方法與精髓，因此仍然在使用面向過程式編程的思路去完成做業。第一次做業中，GetPoly類用於獲取用戶輸入、檢查輸入合法性、獲取多項式並存入相應結構中，poly類用於儲存多項式。而運算部分仍然集中於main方法，因此在度量圖中能夠明顯看出main方法仍然佔用了絕大多數資源。因爲第一做業相對來講難度仍然較低，因此這種程序核心功能集中於一個方法實現的原始思路不會出現太大的問題。可是從第二次做業開始，這樣的思路顯然就會因難度的提高而凸顯出其不合理性。

　　第一次做業的難點我認爲在於輸入的合法性判斷。在輸入的合法性判斷上我和大多數同窗同樣選擇了用正則表達式來解決。通過對正則表達式的學習，發現正則表達式強大的功能與靈活性能夠很好的解決輸入合法性的檢查。但在隨後的測試中，我和同窗們發現，在單行輸入數據很長時，直接匹配正則表達式會出現爆棧的錯誤。因此通過思考，咱們選擇了每次只匹配一個多項式，匹配屢次後將全部匹配到的多項式拼接，與原輸入想對比的方式繞開了爆棧的錯誤。在互測中，第一次做業的BUG有兩個：一、在多項式中只有一項時，會多輸出一個逗號（顯而易見的低級錯誤，在測試時光顧着測試複雜數據，反而忽略了這種最簡單的狀況）；二、輸入21個多項式時不會報錯（顯然是判斷條件中多打了一個等號。。）。兩個BUG都是由於粗枝大葉而出現的錯誤，這一點也體現出了第一次做業在測試上的不足。

第二次做業

度量圖：

 

 

類圖：

　　從度量圖中能夠看出，第二次做業相比第一次做業有了較大的改善，佔用資源最多的是用於將輸入的指令轉換成Request對象的setr方法、用於每次執行完指令後進行滅燈、更新須要指令的指令隊列的updater方法。這兩個方法的主要特色都是須要重複屢次使用，因此佔用了較多資源。第二次做業的難點我認爲主要有兩個。一、如何正確理解5個類的設計要求，並實現5個類協同完成整個程序所須要的功能；二、正確理解指導書，並正確處理各個邊界數據。第一點，因爲每一個人的設計思路不一樣，所在在設計時思路有可能和實現5個類的設計要求不符，互測時我也拿到過爲了知足要求而建立了空類，並無使用的程序。第二點，因爲這一次做業的狀況比第一次做業複雜不少，加之其是基於現實的場景的虛擬，致使在處理不少辯解狀況時同窗們容易有先入爲主的理解，而這種理解有可能與指導書的要求不一致，致使程序中出現了不少非技術性的BUG。

　　第二次做業互測中，我由於沒有將eclipse的編碼改爲UTF-8而被報了一個imcomplete的BUG，除此以外沒有出現其餘BUG。

第三次做業

度量圖：

類圖：

 

 　　第三次做業中，設計的整體思路和第二次做業基本一致 ，只是在更新電梯須要執行的請求隊列、判斷指令是否被執行以及電梯的運行及輸出方面進行較大的改動，而整體運行流程與設計框架依然繼承了第二次做業。從度量圖中能夠看到，因爲第三次做業的複雜度大大提升，因此在用於運行電梯及輸入的elerun方法、用於更新須要執行的請求隊列並判斷同質、捎帶的updater方法佔用的最多的資源。這一點也暴露了在第三次做業中大部分功能的實現都集中於調度類的問題。類圖中能夠看到，爲了知足指導書中的設計要求，全部屬性都設置爲了private，因此實現了大量的get、set函數。

　　第三次做業互評中，我沒有被找到任何BUG，可是由於readme中包含我的信息而被斷定了無效做業，致使本身十幾個小時的努力白白浪費了。在這一次悲劇中，我本身確實有必定的責任，沒有及時瞭解到使用win10自帶的「生成沒有任何可刪除信息的副本」在專業pdf閱讀器下依然能夠看到做業信息。由於本人和周圍同窗大多用chrome查看pdf文件，而這樣的方法確實保證了在chrome下沒法查看我的信息，而且周圍同窗在這三次做業中也幾乎都採用的是這種方法，且沒有出現任何問題，就默認了這種方法的有效性。同時，又由於「第二次做業開始readme再也不要求使用pdf格式」、「在客服羣中通知過此種方法不能有效刪除我的信息」等重要信息只在OO微信客服羣中出現過，而在通知版、指導書中從未說起等綜合緣由，致使了包括我在內的部分同窗的大量努力只獲得了無效做業的結果。

尋找BUG方法

　　第一次做業時，我主要經過根據錯誤分指樹逐個構造數據並測試，再測試一些有關輸入的極端狀況、特殊狀況的方式進行測試。在發現錯誤輸出後，根據構造的數據類型去閱讀具體的有關代碼，尋找錯誤的根源。這樣的方法缺點在於人工成本較高，須要花費較長時間構造數據並進行測試。從第二次做業開始，我和室友們以及周圍同窗集思廣益，找到了效率更高的方法：在測試完各類錯誤輸入的狀況後，進行隨機正確輸入的對拍，在結果不一致時，就能夠肯定參與對拍的某一方出現了BUG。在互測時，直接使用對方的程序與本身的程序進行對拍，能夠較快的發現對方存在的BUG。尤爲是在第三次做業中，因爲狀況複雜，且每一個人的設計徹底不一樣，在不一樣的狀況組合下，有可能會出現獨特的BUG。因此在對拍時進行的大量隨機輸入測試就能較快的發現這樣的BUG。發現BUG後再針對性的閱讀代碼、進行測試，就能找出BUG出現的緣由。

心得體會

　　通過了一個月的面向對象程序設計的學習，我切實感覺到了面向對象與面向過程式編程所存在的巨大差距，在程序規模逐步提高時，也體會到了面向對象式編程給程序員所帶來的便利。而OO獨特的互評機制，更讓我提早感覺到了步入社會後咱們所要面對的是怎樣的環境（大概這就是剛踏入社會的大染缸就被淹死了吧）。世界上沒有公平可言，只有經過本身的努力來減小本身可能會受到的不公待遇。最後但願同窗們在以後的OO做業中都能若有神助，一次AK，同時也但願OO課程的通知機制、統一規定方面能變的愈來愈好，讓助教們、同窗們都能少受委屈，少作無用功。