OO第一次博客做業

嘗試使用Eclipse中的AmaterasUML工具，可是始終安裝不成功，因此類圖是使用的商業版的IDEA自帶的UML Support工具製做。
同理，嘗試在Eclipse Oxygen和Eclipse Java Neon安裝Metrics報錯，使用IDEA的MetricsReloaded分析度量

關於MetricsReloaded：
ev(G)：表示程序的結構化程度，值越大表示代碼段越難維護；
iv(G)：方法之間的緊密程度,二者呈正態相關；
v(G)：判斷程序的複雜程度，值越大表示方法越複雜，在必定程度上能夠看做方法越難維護；

1.第一次做業（多項式加減）

類圖：

度量：

第一次做業能夠看出，Poly類的getArray方法iv(G)和v(G)兩項的值都很大，說明對於方法的抽象不夠，這個方法應該能夠抽象成幾個小部分，這種寫法說明程序比較偏於面向過程。

2. 第二次做業（簡單電梯）

類圖：

度量：

第二次做業的Elevator.calculate()方法的ev(G)、iv(G)和v(G)值都很大，我本身寫的時候也意識到了將大部分的調圖處理放置在一個方法裏面是不合適的，在調試的時候很是麻煩，對於數據的封裝性也很差，可是由於第二次做業比較簡單，因此也沒有進行方法的調整。

3. 第三次做業（ALS電梯）

類圖：

度量：


因爲前兩次沒有注意將不一樣性質的處理方法抽象出來，因此此次將主要的調度仍是寫在一個方法裏面，後期debug的時候出現了很大的問題，也致使了第三次做業的失敗。

分析本身的Bug

前兩次做業比較簡單，因此在程序邏輯設計上並無太大問題，公測和互測檢查出來的Bug都是在細節問題的處理上：好比忘記處理了樓層數字的前零，還有對於同一個錯誤，輸出了兩個錯誤提示信息。
可是第三次做業暴露出了不少問題，致使公測中關於捎帶的測試點基本都掛了。
對比分析了本身的代碼和公測拿到的大佬的代碼以後，意識到了實質問題出在對於面向對象思想的理解和對於程序總體的架構上，好比對於無效輸入和同質輸入，個人處理都是在具體的代碼段使用兩個System.out和continue語句，可是由於程序中須要不少這樣的判斷，因此致使代碼出現了大量的冗餘，而後在指導書更新的時候，須要在每一處修改細節，浪費了大量的精力。而更好的處理方法以下：

class ERROR{
    public static void errorOut(String str, int type) {
        if(type == 0) {
            System.out.println("INVALID[" + str + "]") ;                
        }
        else if(type == 1) {
            str = str.replaceAll("\\(","");
            str = str.replaceAll("\\)","");
            System.out.println("#SAME[" + str + "]") ;
        }
    }
}

構造一個錯誤處理類，使用static修飾類中方法，使用時不須要new一個新對象，須要輸出錯誤時只須要一行ERROR.errorOut(str,type)便可。
其次就是變量命名的問題，好比我最開始使用TIME表示系統時間，而time表示當前請求時間，這種命名方式就很naive，閱讀性不好，無疑是給本身debug的時候增長難度，而好比使用curTime表示系統時間，reqTime表示請求時間就很清晰。

分析別人的Bug

找出別人的Bug的方法，無非就是閱讀別人的源碼和使用本身構造的樣例。
前幾回做業中和室友協做，使用在線文檔的方式根據分支樹構造了比較完成的測試樣例集合，因此在測試別人代碼的時候比較有用。
第一次做業比較簡單，找到兩個Bug；
第二次做業對面公測掛了10個，同質掛了一堆；
第三次做業，拿到一個大佬的代碼，雖然沒有找到bug，不過閱讀源碼也很有收穫。

心得體會

1. 代碼在必定程度上是越精簡越好，冗餘的代碼維護起來十分費勁；
2. 對於面向對象思想的理解：將功能相同的模塊提煉成類以及方法；
3. 總結來講就是寫的代碼太少，對於面向對象的練習不夠。