OO第一次總結做業

第一次OO博客做業

前言

   面向對象課程已經通過了4周的時間。前三次做業所有是關於多項式求導的相關內容，內容由易到難，同時我也開始逐漸深刻感覺學習面向對象的各項特徵，逐漸將本身的編程風格從C向真正的面嚮對象語言轉換。同時我還接觸了DEBUG和互測屋這樣嶄新的學習方式，在閱讀別人代碼的過程當中不斷加強本身的編程能力和學習能力。

本篇博客將結合3次做業內容，分別從題目的理解思路，代碼風格和度量，BUG的產生以及修復和Applying Creational Pattern共4個方面分析我這四周以來的工做。

1、第一次多項式求導做業

第一次做業相對以後的2次簡單許多，可是因爲是第一次運用JAVA編寫這樣有必定規模的程序，對我仍是有必定挑戰的。

我將第一次做業大體分爲3個階段，包括多項式的格式檢查，多項式的求導以及最後的化簡輸出。在第一步的格式檢查中先檢查空格部分，再將空格刪除，用一長條正則匹配全部字符。在求導部分對每一項進行匹配，共有5種格式可能，分別對這5種狀況進行求導，同時將結果存入HASHMAP中，最終在最後的化簡輸出函數中對指數相同部分，以及0，1進行化簡，最終輸出。

         如下爲第一次做業的類圖：

   相信這應該是我所寫過的最面向過程的JAVA程序，整個程序自始至終只有一個類，而且整個程序的結構相似於C程序那樣流水線的順序結構，將全部函數以及數據都封裝在同一個類裏。這直接致使了在第二次做業的沒法擴展，只能推倒重來。

第一次做業BUG分析

在第一次做業個人程序在測試中總共檢出過2個BUG，分別爲正則爆棧以及邏輯判斷式中的計算順序問題。

         首先是正則爆棧問題。在第一次做業中因爲第一次使用正則表達式，沒有采起分段匹配的方法，而是對整段統一一塊兒匹配，以下圖所示。

 

因爲在第一次寫正則表達式時使用貪婪匹配，直接致使程序爆棧。在DEBUG中將其改成獨佔模式進行匹配，得以解決問題，但在風格上無疑是很很差的。所以在後2次做業中進行了逐項匹配。

第二個BUG屬於比較低級的錯誤

 

  問題出如今mlj2中，在BUG修復前沒有括號，而判斷目的是先進行或運算再進行與運算，與默認運算順序不一樣，致使格式判斷出現錯誤。

總結

整體第一次做業難度不高，但因爲是第一次編寫有必定規模的JAVA程序，在程序風格，重構考慮以及細節等不少地方都沒有作到位，也算是給本身長了一次教訓。

 

 

2、第二次多項式求導做業

第二次做業相對於第一次做業增長了sin(x)和cos(x)求導，相對於第一次做業須要增長對於sin(x)和cos(x)的正則識別，同時在求導規則和化簡上增長了必定的難度。整體上格式判斷與第一次求導做業相同，但了可能的三個運算符與數字的組合，須要在第一次求導格式判斷的基礎上增長一個新的判斷函數。在最終結果方面，將每一項變爲a*x^b*sin(x)^c*cos(x)^d的形式，並在最後根據狀況進行化簡。

如下爲第二次做業的類圖：

 

 

  在第二次做業中我首先將整個多項式做爲一個Poly類，對其進行空格檢查。在刪除空格後經過加減號進行劃分，將整個多項式分解爲各個獨立的項，在對每項進行格式檢查後進行求導，將求導造成的 abcd4元組變換成字符串存入Arraylist中。最後將係數項相同的部分以及1和0進行化簡，最後輸出結果。複用了第一次做業的空格判斷函數，但在函數求導上與第一有較大差異。第一次做業使用HASHMAP進行儲存，而這一次使用ARRAYLIST，因而只能大規模重寫。

  整體代碼風格上較第一次有比較大的改善。我總共創建了2個類：多項式類和項類，在多項式類中進行空格和符號的格式檢查，以及最後的化簡輸出工做。在項類中進行每一項的格式檢查以及求導工做。但在細節等不少方面都有能夠增長的地方，例如使用接口進行規範。同時我也沒有讓項類繼承多項式類的部分特性，而是重複編寫了許多相同功能的函數。以及在格式檢查傳遞錯誤信息中我使用了變量傳遞，雖然在原理上可行，可是是不被推崇的編程方法，所以在第三次做業中經過拋出錯誤的方法替代了該部分的方法。

第二次求導做業中的BUG：

         第二次做業在結構上並無BUG出現，但在細節上出現了BUG。在對1進行化簡時沒有考慮項內只有1的狀況，致使將爲1的項整個消去了，產生錯誤。這也提醒我在編寫這樣有必定代碼量的程序時不但要注重整體的思路和結構，還要當心這樣的細節之處。同時在DEBUG時要充分考慮各類狀況。正是因爲這樣的一個小錯誤使我直接掉入C檔，算是吃一塹長一智吧。

 

 

 

3、第三次多項式求導做業

         第三次做業相對第二次做業增長了多項式的嵌套狀況，在求導上覆雜度增長，沒法只經過4元組的形式表示全部的求導結果。同時在格式判斷，項切割等各個方面增長了難度，須要考慮括號等各類新的因素。程序類圖以下所示：

 

 

個人程序將可能出項的結構狀況大體歸爲3類，包括多項式類(Poly)、項類(MPoly)和因子類(Subpoly)。在多項式類中我大體進行了3項工做，包括多項式的空格以及符號檢查，對多項式中項的劃分以及將項的求導結果進行整合，造成多項式的求導結果。在項類中我大體進行2項工做，對項進行分割造成因子，同時將因子求導結果進行整合，造成項的求導結果。在因子類中進行2項工做，包括對因子格式的檢查以及對因子的求導。在這3類以外爲了方便區分系統EXCEPTION以及格式錯誤2種狀況引發的WRONG FORMAT!，我定義了一個自定義異常DException.

因爲第二次做業考慮對於擴展的需求，在這一次做業中我成功複用了第二次做業全部格式判斷函數以及部分求導函數。但這一次做業在細節上仍然有不少不足之處。個人思想仍然沒有完全擺脫C的限制，在第二次做業中一樣沒有使用類的繼承以及接口等JAVA特性的功能。同時能夠從類圖中看到，我沒必要要的屬性以及類內部分方法的複雜度仍然太高，這都是我在接下來亟需轉變的問題。若是仍然將本身的思想侷限於面向過程當中我勢必會遇到瓶頸和障礙。

第三次做業BUG：

在第三次做業中因爲我的能力和時間有限並無對整個多項式進行化簡工做，所以相比前2次做業在化簡時的BUG，我這一成功經過了全部強測案例。同時爲了不沒必要要BUG的出現，我在另外一方面增長了最終表達式的複雜性，方法是將全部的+轉變爲+1*,負號轉化爲-1*，但卻忘記考慮了一種特殊狀況，即將 sin(-23)轉變爲sin(-1*23),致使了互測時BUG的出現。這也提示我在編程時要從實際出發，若是一直使用這樣的小聰明一定會致使意外出現。

第三次做業總結

         在第三次做業中我成功實現了對前2次做業的擴展，經過遞歸以及進一步的劃分類的方法實現了嵌套求導。但在類繼承、接口實現這些JAVA特性結構的使用上仍然有很大的不足之處，同時並無實現最終的化簡工做。

4、關於互測屋和DEBUG

         我對別人的DEBUG方法相對而言分爲2步。第一步即在本身編寫程序的過程當中將可能出現的BUG記下來，而後在互測時攻擊別人，其中主要包括格式錯誤以及可能出現的爆棧錯誤。例如空串，1,1-1,0*x^0等這樣的常見錯誤。一般這種方法特別有效，將近70%的錯誤均可以經過這樣的方法解決。第二步就是閱讀他人的代碼。因爲要閱讀將近7我的的代碼，沒有時間一行一行讀，我採起的作法是挑選重點讀，一般是匹配的正則表達式，求導過程以及最終的化簡步驟等幾個場景愛你犯錯誤的地方。經過這2步的配合90%的錯誤都能被找到。

在3個星期的互測中，經過閱讀他人的代碼我也開拓了眼界，學到了很多東西。包括工廠函數，以及優秀正則表達式書寫等各項新的知識。同時也促使我充分檢討本身糟糕的代碼風格。

5、Applying Creational Pattern

         因爲使用JAVA仍然不夠熟練，在3次做業中我都沒有充分考慮到重構的問題。三次做業的求導過程都大相徑庭，所有重寫。但格式判斷函數，即對空格以及加減號合法性判斷獲得了複用。

6、總結

    通過了3個星期的多項式編程，我初步掌握了JAVA的編程方法和麪向對象的基本思想，目前仍有2項不足之處，首先個人思想仍然很大程度上收到C的限制，老是想經過面向過程的方法解決問題。第二是對JAVA語言的部分特性不太熟悉，當別人接口，繼承，工廠函數很是熟練時，我仍然在把JAVA當C寫，使用多個函數定義想解決一切問題，這顯然是不合適的。在接下來的學習和編程中我須要充分認識到本身的不足，從他人的代碼，網上以及課堂上充分學習，使本身成爲一個合格的JAVA程序員。