一、對面向對象的了解
在大一學習python的過程中，接觸了一些面向對象的思想。在三月伊始，java的面向對象程式設計就成了我的主要任務。對我來說，面向對象程式設計就好像裝修一個房子，我根據各種家具的特性和功能執行個體化很多真實存在的家具并且擺放到合理的位置上，我知道他們可以實作什麼功能，但我們不需要知道它的内部實作是什麼樣的。這是一種封裝的思想，實作一種高内聚和低耦合的狀态，它很好地提高了程式設計的效率。java語言還有一個繼承的特性，表面上看，它改善了程式設計中代碼重用的冗長感，而更重要的作用是，它建構了一個完整，清晰有條理的體系。
二、三次作業的度量分析
1、多項式計算
圖一 多項式計算類圖
Poly用來生成多項式對象和多項式計算，ComputePoly包含主方法和對多項式的解析。結構比較簡單，清晰。
度量情況如下：
圖二 多項式度量結果
可見，ComputePoly 類中的複雜度和嵌套會比較多，究其原因，parsePoly方法中雖然使用了正規表達式，但是在識别各個格式錯誤上還是使用了控制流語句，并且沒有設立專門的異常類，出現很多代碼複用的情況。
另外，此次作業也用面向過程的方式實作了出來，具體是通過狀态機完成的，這種方式下結構很緊密，對于這樣小一些的工程還是可以實作，若工程規模一大，結構就會不清晰，不易調試。面向對象就會讓整個結構比較清晰，各司其職。
2、傻瓜排程式電梯
圖三 傻瓜排程式電梯類圖
總體結構也較為清晰，是以Scheduler為核心的電梯體系，其中Floor類中包含main方法和輸入請求的篩選。篩選後執行個體化Request類并且加入請求隊列，進而在Scheduler類中處理隊列，直到隊列為空。具體處理過程交由Elevator類中的方法。
圖四 傻瓜排程式電梯度量
可以看出，主要問題出現在Floor類中，很顯然，在main方法裡放入很多格式篩選的條件是不恰當的。與多項式中的問題一樣，使用了很多控制流語句來區分各個格式情況對複雜度影響很大。
3、ALS排程式電梯
圖五 ALS排程式電梯類圖
結構較之于作業二沒有本質的變化，與第二次作業不同的在于新建立了一個捎帶集，對于被捎帶請求有一套不同的運作方法。
圖六 ALS排程式電梯度量
Scheduler仍是整個程式的核心，而SchedulerExtend是繼承了Scheduler，override了其中的方法并且新加了屬于自己的方法。電梯的運動方式用接口歸納了起來。複雜度等方面和第二次作業的問題是一樣的。
三、遇到的bug
1、正規表達式的錯誤
忽略了前導零的存在。以及在第二次作業中樓層上下限的問題。
這些都是同學由于正規表達式不正确導緻的。因為我始終對自己的正規表達式不放心，于是隻在第一次作業中分區塊使用了正規表達式（結果就是控制流太多導緻程式複雜性加大），但是正規表達式确實是一個值得好好學習的内容，在java文檔中可以看到很多通過正規表達式完成的方法。還要了解每個方法對正規表達式的使用，不然很容易踩到這個方法的坑。例如，match方法中的貪婪比對需要加-1參數。
2、對忽略請求沒有考慮全面
第三次作業中，看到同學對相同請求仍然執行的情況。也就是對同質請求的判斷不夠充分。
3、對使用方法的不熟悉
如果不加try catch，在一些方法裡面會出現空引用，OutOfBound等的異常，直接導緻程式的崩潰。
4、邏輯錯誤
在第三次作業中對特定情況下計算時間用了錯誤的基礎值。
5、強制轉換的不注意
四、測試程式的政策
首先，檢查正常功能的實作是否有誤，主要是在臨界值上面進行測試，然後進行壓力測試。觀察使用到的函數，在查閱文檔後對這些函數進行特殊值的測試。最後檢視代碼關鍵部分的邏輯是否有誤并且構造特殊的測試集。
五、感觸
豐富的内置函數确實讓開發變得輕松，再加上java5的一些新特性，使得java開發與之前的C語言開發有很大的不同，現在最大的問題還是在于如何進行統籌的設計，以及一些算法的設計上面，若是一些方面沒有考慮成熟就會導緻代碼的可擴充性很差，并且一個不好的算法在後期調試的時候會帶來很大的麻煩。在設計算法的時候先要做好情況的化歸和歸并，還有就是在後期擴充，新增一些要求的時候也要讓它跟原本的程式融合在一起，否則這種缺哪兒補哪兒的方式會讓程式冗長淩亂還易出錯。