oo第一單元總結

OO前三次做業總結

第一次做業

設計思路

Term做爲一個項，包含係數、指數。

Poly爲一個多項式，內部有ArrayList<Term>，方法包括排序、合併同類項、求導、輸出等。

代碼分析

指標含義

ev(G)：基本複雜度（Essential Complexity），此指標是用來衡量程序非結構化程度的，非結構成分下降了程序的質量，增長了代碼的維護難度，使程序難以理解。所以，基本複雜度高意味着非結構化程度高，難以模塊化和維護。實際上，消除一個錯誤有時會引發其餘的錯誤。

Iv(G)：模塊設計複雜度（Module Design Complexity），此指標是用來衡量模塊斷定結構，即模塊和其它模塊的調用關係。軟件模塊設計複雜度高意味着模塊耦合度高，這將致使模塊難於隔離、維護和複用。模塊設計複雜度是從模塊流程圖中移去那些不包含調用子模塊的斷定和循環結構後得出的圈複雜度，所以模塊設計複雜度不能大於圈複雜度，一般使遠小於圈複雜度。

 v(G)：是用來衡量一個模塊斷定結構的複雜程度，數量上表現爲獨立路徑的條數，即合理的預防錯誤所需測試的最少路徑條數，圈複雜度大說明程序代碼可能質量低且難於測試和維護，經驗代表，程序的可能錯誤和高的圈複雜度有着很大關係。

以上指標含義來自http://www.javashuo.com/article/p-hrljazti-hd.html

經過上面的指標能夠看到Term.getCoefficient(String)方法的基本複雜度較高，程序結構化程度不夠。

Poly.printCoefficient(Term)和Poly.printIndex(Term)兩個方法的模塊設計複雜度和模塊判斷結構複雜度較高。關於輸出部分的設計思路：Poly.print()方法進行輸出的時候，首先輸出係數，同時在其中判斷指數（關於指數爲零的優化），而後輸出指數，此中判斷係數，同時根據指數判斷是否輸出x。這部分的設計比較複雜，耦合度也較高，須要改進方法進行優化。

公測

在輸出指數時沒有判斷係數是否爲0，因此會輸出*x^-30這種結果。

優化方面,沒有考慮到正向提早在某些狀況下可使輸出的長度變短。

互測

被hack：

(1） 同公測bug

(2） 一種WF，即連續常數相乘，如-12x會輸出求導結果，沒法判斷 其爲Wrong Format！

hack：

主要關注WF的問題，方法也主要使經過分析其正則表達式。（第一次做業讀完了同room的7份代碼，雖然能夠比較全面地發現問題，可是比較累。）

總結反思

第一次oo做業中出現的問題總結以下：

（1）結構化設計的思想沒有很好地實踐，在寫程序地過程當中還有面向過程的思惟。

（2）最開始採用大正則，沒有考慮到爆棧的問題，修改成用小的正則表達式進行獲取階段後解決。

 

第二次做業

設計思路

Term做爲一個因子，包含係數，x的指數，sin(x)的指數，cos(x)的指數。

Poly做爲一個多項式，內部包含ArrayList<Term>，相比於第一次做業，在輸出方法和求導方法進行了補充，增長了正項提早方法(advance)和sin(x)^2+cos(x)^2=1的化簡方法。

代碼分析

公測

在公測中沒有Wrong Answer的測試點。

關於性能：實現了正項提早和sin(x)^2+cos(x)^2=1的優化，可是合併同類項出現了問題在第一次做業中合併同類項時採用的是先按照x的指數升序排序，而後進行合併，在第二次做業中想採用和第一次做業相同的思路，可是僅對x的係數進行排序，致使x指數相同時，不能實現對sin(x)和cos(x)的排序。因此性能分......

互測

被hack：0

hack：0

總結反思

二次做業偷偷懶，三次做業火葬場。

 

第三次做業

設計思路

基本項：Constant、x、sin(x)、cos(x)

組合項：加法項（Add）、乘法項（Multiply）、嵌套項（Sinnest、Cosnest）

按照加法項、乘法項、嵌套項初級拆分表達式，最終獲得基本項，整個表達式呈樹狀結構，遞歸求導和輸出。

代碼分析

 

Bug修復

由於第三次做業在表達式的處理上出現了嚴重的問題，致使公測和互測同時炸掉，因此兩部份內容合併爲bug修復進行總結。

這次做業表達式的分解和存儲所有經過尋找每種組合類型的特徵來完成，如加法項經過識別括號以外的+-號來判別，乘法項經過識別括號以外的*來判別，須要考慮到某些特殊的狀況，如（x+x）沒有括號外的正負號，但倒是加項、-(sin(x))存在括號外的正負號，但倒是嵌套項，主要問題出在整個表達式的外面嵌套了能夠去掉的括號，須要經過判斷開頭和結尾的括號是不是一組進行去括號處理，同時要注意括號外的正負號問題。

sin和cos的嵌套項經過正則表達式來完成，可是須要注意的是，若是嵌套的部分是個表達式因子須要加括號，不然爲Wrong Format，不論是否是表達式因子，在建立新的對象時都須要進行去括號處理，尤爲嵌套因子是基本項地時候，去括號問題很容易被忽略，程序可能會出現 RUNTIME_ERROR 如sin((0))。

hack：構造特殊的輸入數據，如上所述對同room代碼進行測試，互測過程當中發現了不少本身的bug（暗暗後悔）。

反思總結

關於化簡問題，架構問題使得化簡變得複雜，須要考慮的狀況不少，最終放棄了化簡，深入認識到了架構的重要性。

關於表達式處理問題，在上部分bug修復中已經對出現的問題作出了總結，以後在寫程序的過程當中，會盡可能全面地考慮輸入可能出現地狀況。