OO前三次做業總結

1、對面向對象的理解

　　在大一學習python的過程當中，接觸了一些面向對象的思想。在三月伊始，java的面向對象編程就成了個人主要任務。對我來講，面向對象編程就好像裝修一個房子，我根據各類傢俱的特性和功能實例化不少真實存在的傢俱而且擺放到合理的位置上，我知道他們能夠實現什麼功能，但咱們不須要知道它的內部實現是什麼樣的。這是一種封裝的思想，實現一種高內聚和低耦合的狀態，它很好地提升了編程的效率。java語言還有一個繼承的特性，表面上看，它改善了編程中代碼重用的冗長感，而更重要的做用是，它構建了一個完整，清晰有條理的體系。

2、三次做業的度量分析

一、多項式計算

圖一 多項式計算類圖

 

Poly用來生成多項式對象和多項式計算，ComputePoly包含主方法和對多項式的解析。結構比較簡單，清晰。

度量狀況以下：

圖二 多項式度量結果

 

可見，ComputePoly 類中的複雜度和嵌套會比較多，究其緣由，parsePoly方法中雖然使用了正則表達式，可是在識別各個格式錯誤上仍是使用了控制流語句，而且沒有設立專門的異常類，出現不少代碼複用的狀況。

另外，這次做業也用面向過程的方式實現了出來，具體是經過狀態機完成的，這種方式下結構很緊密，對於這樣小一些的工程仍是能夠實現，若工程規模一大，結構就會不清晰，不易調試。面向對象就會讓整個結構比較清晰，各司其職。

二、傻瓜調度式電梯

 

圖三 傻瓜調度式電梯類圖

 

整體結構也較爲清晰，是以Scheduler爲核心的電梯體系，其中Floor類中包含main方法和輸入請求的篩選。篩選後實例化Request類而且加入請求隊列，進而在Scheduler類中處理隊列，直到隊列爲空。具體處理過程交由Elevator類中的方法。

度量狀況以下：

 

圖四 傻瓜調度式電梯度量

能夠看出，主要問題出如今Floor類中，很顯然，在main方法裏放入不少格式篩選的條件是不恰當的。與多項式中的問題同樣，使用了不少控制流語句來區分各個格式狀況對複雜度影響很大。

三、ALS調度式電梯

 

圖五 ALS調度式電梯類圖

結構較之於做業二沒有本質的變化，與第二次做業不一樣的在於新建立了一個捎帶集，對於被捎帶請求有一套不一樣的運行方法。

度量狀況以下：

 

圖六 ALS調度式電梯度量

Scheduler還是整個程序的核心，而SchedulerExtend是繼承了Scheduler，override了其中的方法而且新加了屬於本身的方法。電梯的運動方式用接口概括了起來。複雜度等方面和第二次做業的問題是同樣的。

3、遇到的bug

一、正則表達式的錯誤

忽略了前導零的存在。以及在第二次做業中樓層上下限的問題。

這些都是同窗因爲正則表達式不正確致使的。由於我始終對本身的正則表達式不放心，因而只在第一次做業中分區塊使用了正則表達式（結果就是控制流太多致使程序複雜性加大），可是正則表達式確實是一個值得好好學習的內容，在java文檔中能夠看到不少經過正則表達式完成的方法。還要了解每一個方法對正則表達式的使用，否則很容易踩到這個方法的坑。例如，match方法中的貪婪匹配須要加-1參數。

二、對忽略請求沒有考慮全面

第三次做業中，看到同窗對相同請求仍然執行的狀況。也就是對同質請求的判斷不夠充分。

三、對使用方法的不熟悉

若是不加try catch，在一些方法裏面會出現空引用，OutOfBound等的異常，直接致使程序的崩潰。

四、邏輯錯誤

 在第三次做業中對特定狀況下計算時間用了錯誤的基礎值。

五、強制轉換的不注意

4、測試程序的策略

　　首先，檢查正常功能的實現是否有誤，主要是在臨界值上面進行測試，而後進行壓力測試。觀察使用到的函數，在查閱文檔後對這些函數進行特殊值的測試。最後查看代碼關鍵部分的邏輯是否有誤而且構造特殊的測試集。

5、感觸

　　豐富的內置函數確實讓開發變得輕鬆，再加上java5的一些新特性，使得java開發與以前的C語言開發有很大的不一樣，如今最大的問題仍是在於如何進行統籌的設計，以及一些算法的設計上面，如果一些方面沒有考慮成熟就會致使代碼的可擴展性不好，而且一個很差的算法在後期調試的時候會帶來很大的麻煩。在設計算法的時候先要作好狀況的化歸和歸併，還有就是在後期擴展，新增一些要求的時候也要讓它跟本來的程序融合在一塊兒，不然這種缺哪兒補哪兒的方式會讓程序冗長凌亂還易出錯。