OO第一單元總結

概述：

　　面向對象第一單元的做業是多項式求導，從第一次的簡單多項式，到第二次的帶有sin和cos的多項式，到第三次的帶有嵌套的多項式。從本單元的做業中，我初步瞭解了面向對象程序架構的基本思想，同時也學習到了一些經常使用工具，如正則表達式以及java中一些基本庫的使用。

1、程序分析

第一次做業

一、思路

　　第一次做業輸入格式較爲簡單，僅含有冪函數和常數項。解決思路也比較簡單，即便用正則表達式輔助將項分開，對每項內部進行分析，獲得各項的係數和指數。求導時按指數分類討論。對於結果的同類項合併，使用一個以指數爲key的Hashmap：若表中含有當前指數的項，則合併係數。最後遍歷Hashmap輸出結果。

 二、度量分析

　　　　　　　　

　　第一次做業我主要寫了兩個類，主類Main負責輸入的一些預處理，Item類負責對每項進一步解析，完成獲得係數指數和求導的功能。這裏我仍是有一些面向過程的思想，預處理不該該在入口中進行而應該單首創建一個類來管理。　　　

　　　　   　　　　　   

　　　　   　               

　　第一次做業的代碼iv(G)和v(G)較高，說明個人程序高內聚且內部結構複雜，這說明在模塊功能內部的實現中還有面向過程的思想，缺乏模塊的功能分類。

第二次做業

一、思路

　　第二次做業的輸入在第一次做業的基礎上多了兩種三角函數，可是總體的解決思路還是不變。即先預處理，再使用+-號分割出每一項，在每一項中再使用*號分割出每個因子進行解析，解析事後利用乘法法則進行求導。對於求導結果的合併，咱們能夠把每一項看作是一個三元組<a,b,c>，其中abc分別是x、sin(x)、cos(x)的指數，將這個三元組做爲Hashmap的key，剩下的就和第一次做業相同了。

二、度量分析

　　　　　　　     

　　第二次做業我寫了三個類，Main類負責預處理和程序入口，Term類對項進行解析並進行求導操做，IndexKey類是我本身寫的做爲Hashmap的key的類，重寫了equals()和Hashcode()方法。

　　　　                    

　　　　                    

　　第二次做業總體結構上仍是繼承了第一次做業，我認爲在輸出那裏邏輯很複雜，結構沒有設計好，爲了經過格式檢查把一個函數分紅三部分，結果結構化程度仍然很高，最終BUG也是出如今這個部分。

第三次做業

一、思路

　　第三次做業在第二次做業的基礎上容許嵌套，即表達式項做爲因子和三角函數的自變量存在。因爲不知道嵌套的深度，一個顯而易見的思路就是使用遞歸處理。在本次做業中我創建了一個專門用來管理操做的類Str，裏面有對錶達式解析的方法能夠被遞歸調用。對錶達式的解析按照指導書的方法構造樹形結構，全部基本項如三角函數、冪函數、常數，還有加法和乘法關係都是一個接口Func的實現，而這個接口自己有toStr()和求導方法。遞歸構建好表達式樹以後直接對根節點使用求導方法就能夠獲得結果。

二、度量分析

　　　                 

　　第三次做業我使用了工廠模式。全部的因子和關係都是一個接口Func的實現，程序在總體結構上清晰了不少，擴展性也提升了。可是因爲遞歸的結構，使得結果的化簡變得比較困難。我在每一個因子和關係的求導方法中加入了一些斷定，例如在加法關係求導方法中若左右兩項都爲常數則合併。可是因爲各項的複雜性很難作到全部的同類項都被合併，這也是從此一個須要改進的地方。

　　　　                       

　　　　                       

　　第三次做業的優勢在於使用了工廠模式使程序的結構更加清晰，可拓展度提高。同時使用了Str類來管理解析字符串的方法，在Main中只完成輸入和輸出的工做，總體更加的面向對象化。可是仍舊有一些缺點存在，例如優化的部分和求導部分的重合以及優化的功能實現不全，還有一些方法的屢次調用增長了程序總體的複雜度。

 

2、BUG分析

第一次做業

（1）非法字符，沒有判斷輸入表達式含有非法字符的狀況。

（2）優化問題，結果中的負數爲係數時前面多輸出了一個+號。

第二次做業

（1）沒有處理首項含有+-號且第一項是x/sin(x)/cos(x)的特殊狀況。

（2）優化處理時，若是係數是+-1且x/sin(x)/cos(x)的指數都爲0時，輸出會爲空，實際應該爲+-1。

第三次做業

（1）在Add()和Multiply()方法中的化簡判斷中，使用了遞歸式做爲判斷條件，致使屢次重複遞歸，公測超時。

 

3、互測策略

　　在第一次做業的互測中，我主要仍是經過讀組裏每個同窗的代碼本身手動構造測試樣例進行hack，找到的BUG可能是WRONG FORMAT類考慮不周全的錯誤。這種方法耗時較多，效率也比較低下。

　　在第二次做業的互測中，我使用了Bash腳本批量測試+讀代碼定點打擊結合的方法，效率有所提高。

　　在第三次做業的互測中，輸入的表達式已經能夠很是複雜，因此我使用的是自動化生成的測試數據+本身構造的數據作測試。對於結果的正確性，因爲同窗們的表達式五花八門且很是長，用肉眼已經很難進行判斷，因而我使用了python的sympy庫對錶達式相等進行判斷。

 

4、Applying Creational Pattern

　　第一次做業面向過程思想還很嚴重，應該對預處理方法單獨建類管理，並且基本沒有可擴展性。

　　第二次做業是在第一次做業基礎上寫的，因此總體程序的層次也是很難看，若是能把每一種因子單獨建類，第三次做業就能直接利用了。

　　第三次做業使用了工廠模式，程序層次性更好，可拓展性加強，可是優化部分不盡如人意，我認爲若是進行重構的話要新建一個類對求導結果整個字符串進行項合併、因子合併和去括號操做。

 

5、總結與反思

　　在這三週的時間裏算是初步接觸OO這門課的模式。自己java這門語言有編程經驗的話很容易上手，也有不少方便的庫能夠直接用，省去了很多麻煩。我的學到的比較重要的幾點一是寫完程序必定要作覆蓋性測試，我就是常常週日一夜肝過了公測週一週二就只作優化和簡單的測試，致使在互測構造測試數據hack別人的同時也不當心發現了本身的BUG；二是在優化的時候必定要事先想清楚本身的優化的適用範圍，以及面對一些特殊狀況的判斷，或者說在條件不容許時乾脆不優化保證本身的正確性也是一種策略，半斤八兩的優化還不如沒有；三是多看下大佬們的代碼，我在gitlab上看到了很多漂亮的大佬代碼有不少值得我去學習。