Java第四單元暨面向對象課程總結

 

1、第四單元做業框架

一、UML類圖解析器

    （1）設計策略

    做爲對UML的入門，此次做業主要考察了咱們對於UML類圖的構成要素的解析方法，並經過這種方法加深咱們對於UML的理解。

    對於從UML圖中解析出來的信息進行分析與彙總，實現對於UML類圖的各類元素（包括類的個數、特定類中所包含的屬性個數等）的查詢。在作此次做業時，我將各類元素（UMLClass、UMLAttribute等）進行了分門別類的存儲，使得元素可以對應所在的類，實現查詢功能。

（2）類圖

         因爲本次做業只是對於UML類圖中元素的解析，因此只須要將各類元素分門別類地initial處理一下就可以實現功能，因此我只是用了一個類來解決這個問題（所以只截取了一個類的視圖）。以上便是本次做業的大致框架（seekforinterfaces、seekforancestor分別是處理interfaces、class之間的繼承，seek、todo分別是這兩個方法的遞歸作法）。

（3）度量分析

 

二、解析器的拓展（順序圖、狀態圖）以及基本規則的驗證

（1）設計策略

    在UML類圖解析器的基礎上實現對於順序圖和狀態圖的解析，實際操做流程並無改變，都是經過對於存儲各類不一樣元素的相關信息實現對應因素的關聯，與第一次做業相似。

    而對於基本規則的驗證（元素重名、循環繼承、重複繼承），則是本次做業的難點所在。因爲第一次做業須要經過遞歸實現對於最頂級父類的查詢，若是出現循環繼承則在查詢的過程當中會發生死循環，因此在咱們實現繼承的查詢時，咱們必須得保證當循環繼承發生時，咱們要有方法使之「停下來」。

    在個人設計思路中，我在發現循環繼承的類（接口）時將該類的繼承尋找工做停下來，並將其最直接的父類從新賦予它（保證其餘類在測試是否循環繼承時不受影響），並將該類從就緒隊列中剔除，保證它不會干擾到其餘類的尋找工做。

（2）類圖

    與第一次做業相比，第二次做業因爲多種圖的區別，我加入了不一樣的類對於不一樣的圖進行了信息的初始化工做，代碼量較第一次做業有了一個飛越。

（3）度量分析

 

 

 

2、四個單元框架的改進及oo方法理解的演進

（1）框架改進

    在本學期oo課程的學習過程當中，咱們一共經歷了求導、電梯調度、JML語言的探索以及UML工具的探索一共四個單元的學習。在學習第一個單元時，我對於框架的理解還不夠透徹，程序大多一個到兩個類，將各類方法都堆積在構造器中，企圖以一個程序做爲方法實現的所有內容，最終也形成了個人代碼可塑性不好，基本上每次做業都須要重構。

    而在學習二三單元時，我可以根據多種方法的實現結合成一個類，保證了代碼的可讀性。因爲官方接口的提供，個人做業可以逐步「適應」短而精的方法實現，在代碼的規範性方面有了很大的提高。但在代碼的拓展性方面個人做業仍有所欠缺。例如在電梯調度的過程當中，個人第一次做業（傻瓜電梯）並無使用樓層開關門的逐級判斷，而是直接令程序sleep乘客從起點樓層到終點樓層的時間，致使在後面做業中須要對於電梯升降過程的方法實現進行重寫，浪費了時間也錯失了鍛鍊實現代碼可拓展性的良好機會。

    在第四單元的鍛鍊中，我可以很清晰地使用第一次做業的類圖處理方法對於順序圖和狀態圖實現處理，代碼可拓展性有了較大的提高（固然也有較爲類似的因素在其中）。可以經過繼承等方式實現類的有序管理，實現了必定程度上的突破。但在命名方面仍有瑕疵，隨性的命名方式使得我在讀本身的代碼時都會遇到不知道方法或是變量是幹什麼的窘境，這也是我在接下來的代碼編寫過程當中所須要注意的。

 

（2）oo方法理解的演進

    在學習這門課的最開始，我覺得oo是實現處理某個具體問題的課程。因此在個人潛意識裏，可以最準確地實現所須要的功能就是一個好程序。

    因此我在前兩次做業中堆積「屎山」代碼，只爲了可以在一個類中實現所須要的功能。然而對比強測組內其餘同窗的代碼，我發現我本身彷佛更喜歡讀他們的代碼？在代碼的可讀性上，我發現我存在着巨大的問題。

    而後就是第二單元以及第三單元，一個是對於電梯調度時間的限制，一個是對於程序CPU時間的限制，讓我明白了程序的性能也是程序好壞的重要評判條件。只追求正確性並不能作出一份好的代碼。

       oo（面向對象）讓咱們學習瞭如何去實現一個需求，讓咱們知道了封裝、繼承和多態，也讓我在實際寫程序的過程當中主義代碼的可讀性和延展性，養成了良好的寫代碼習慣。

 

 

 

3、測試理解與實踐的改進

    在本學期的面向對象課程中，每次做業的評判有中測和強測之分。中測的樣例較爲簡單，並不能支持咱們必定可以經過強測。因此作好數據的自我測試也是重中之重。

    因此我知道了如何去使用對拍器。經過對拍器中數據的自動生成，我能夠不用再像求導的前兩次做業同樣本身去苦心積慮地編寫數據，而直接由計算機實現數據的自我測試。從第一單元的第三次做業開始到第三單元結束，個人代碼充分享受到了對拍器的「紅利」，也在正確性方面有了必定的保障。

    然而從第四單元開始，UML文件特殊的輸出方式也讓我很難實現對拍器的生成。因此手繪UML圖成爲了我在這個單元測試的關鍵。考慮極端、邊界狀況是我在畫這些圖過程當中所最須要注意的地方，也是我在測試過程當中的難點所在。

    經過四個單元的測試以及自我測試，邊界、極端狀況永遠是一個合格程序可否實現優秀的重要決定因素，對拍器在這方面也有必定的短板（很難造出十分極端的數據）。因此在本身測試的過程當中，作好本身對於這些狀況的判斷，是我在debug過程當中的一大理解與體會。

 

 

 

4、課程收穫

    從一個在學期開始對於java（須要學習的語言）、idea（須要使用的工具）近乎一竅不通的狀態，到可以熟練使用idea寫出千行代碼而不多犯錯，我在這個學期獲得了很大的收穫，可是在細數這些收穫時，我卻又不知道該從什麼方面提及。

可能在我看來，最大的收穫就是教會了我應該如何去看待本身所寫的代碼。僅僅實現了所須要的功能是不行的，在這個性能十分重要的時代裏，如何簡化本身的代碼，實現程序的快速運行和所佔空間的優化，也是咱們在編寫程序過程當中所須要注意的。

    同時，我一貫不太注重的代碼風格在這個學期的面向對象課程學習過程當中也獲得了很大的優化。因爲以前的數據結構、計算機組成等課程更加註重一個程序功能的實現，代碼風格歷來都不是咱們學習成績的影響因素，因此我在寫代碼時也常常會十分隨性。可是當面向對象設置了咱們做業的規範要求並設立了多人互相交換檢查做業的機制時，我也才意識到本身的代碼風格對於別人的理解以及程序後續的開發工做是有多麼的重要，也可以在每次做業中都細心檢查本身的代碼風格，養成這一良好習慣。

    授人以魚，不如授人以漁。Java語言的學習在我看來反而並非這個課程最大的收穫。oo課程的一大優勢就是他所教的內容在咱們從此的學習過程當中都有用，而不只僅在java這一個方面。從對拍器的搭建開始（有用python），到研討課上的分享，本身去嘗試新鮮的東西才能保證咱們在計算機領域的不斷進步，也能幫助咱們這些菜鳥快速成長。

 

 

 

5、對課程組的建議

（1）上機內容的調整

    本學期的上機前緊後鬆。從一開始是上午剛講新知識點，以及下午要求編寫實現某個功能（以這些新知識點爲基礎）的代碼，難度太大而且在我看來也沒有什麼實際的練習意義；到後來有把難度降得太低，只須要認圖說話就能作完實驗，交一份可以經過編譯的程序也成了走形式的一個項目，彷佛也是不太穩當。若是可以將上機內容在早上上課時提早告知，讓咱們在聽課的同時可以揣摩上機題目，或許可以有更好的效果。

 

（2）做業難度梯度的調整

    在我實際編寫代碼的過程當中，我認爲第四單元第一次做業的難度設置較爲不合理。包括繼承關係的處理以及對於每一個元素中所包含的信息的歸類在是實現上存在較大的難度。相比之下，第二次做業的難度反而都集中在類圖基本規則的處理上，相較於第一次做業反而顯得並不太難。因此我但願在後續的課程開展中作好難度的調控，好比像將第一次做業裏繼承關係的考察放到第二次做業中或許難度層次會更好一些。

 

（3）hack組的調整

       在咱們的互測環節中，hack機制並不會懲罰屢次hack同質錯誤的「狼人」，但在實際修復過程當中部分不當心點擊「非合併修復」的同窗就會吃虧。因此在個人觀點裏，可否在現有的房間分配基礎上創建一個相似「信譽積分」的榜單，將那些「狼人」儘可能同時集中在一個房間裏，這樣也能增長一些「狼人」屢次hack同一錯誤的代價，儘可能讓咱們在互測過程當中能對準某個具體錯誤hack，而不是盲目去碰運氣。