OO第一次博客做業（第一單元總結）

Q：菜是綠的，雞是黃的，那菜雞是什麼顏色的？

A：紅的，強測全WA了，能不紅麼。

菜不菜的問題先不說了，認真研究一下此次的題目，以及WA的緣由吧。

程序結構簡析

三次實驗的核心結構都是差很少

第一次的沒什麼好分析的，每一個Item能夠用固定的方式表示：num * x ^ n（暫且不考慮格式），而後拼成表達式就好了。

 

第二次，以Item爲最小單位顯然是不現實了，每一個Item的項數和項的種類都不肯定，那麼就用抽象類Factor做爲基本單位，常數因子、冪函數因子、sin函數因子和cos函數因子做爲該類的具體實現。

每一個Item用Arraylist<Factor>實現（不會用Hashmap），每一個表達式Expression又用Arraylist<Item>實現。

繼承關係很容易看出，由Expression爲父類，子類Item，而後是抽象類Factor和實現Factor的四個子類。

全部的類都實現一個求導接口，從最底層的四個Factor實現類寫起，Item的求導採用乘法求導公式循環求導，Expression求導採用加法求導公式逐個求導。

簡化的方法，就是將每一個項變爲常數因子*冪因子*sin因子*cos因子的標準形式在進行相似第一次做業的簡化。

雖然第二次的重構很是痛苦，可是好處是第三次求導能夠特別快速地進行：只須添加一個繼承Factor類的表達式因子，修改一下sin函數因子和cos函數因子，就能夠實現第三次做業的基本功能了。

因爲第三次做業簡化要求太複雜就不作簡化了。

 

這裏只放出最後一次做業的度量結果，從結果上看，還有很大的優化空間，主要是表達式處理上有很粗糙的地方，表達式讀入的方式仍舊過於面向過程，寫了冗長的函數體。

分析本身程序的BUG

BUG的緣由真沒什麼好分析的，前兩次都是在簡化的時候發生了對輸出的錯誤處理。可是，兩次採用的簡化方法並不相同，因此致使BUG的緣由也不徹底相同。

第一次的簡化策略是，逐項輸出，以項爲最小單位進行簡化。在簡化中，要考慮常數、冪指數爲0、一、-1等的狀況。輸出表達式時，用+或-進行鏈接。錯誤的緣由是在常數爲0時多輸出了一個+號，項卻已經被簡化沒了。

第二次的簡化策略還是以項爲最小單位進行簡化，但因爲此時的最小單位爲因子，因此簡化起來和第一次相差很大。此次是根據未簡化時產生的字符串按正則表達式簡化，但因爲狀況考慮疏忽，致使簡化了不應簡化的狀況，強測出現大量BUG。這就是一個教訓：在第一次做業的BUG修復以後，在容易致使BUG的薄弱環節上就不應另起爐竈了。

除此以外第二次還有一個地方在拷貝代碼時少改了一個變量名，致使求導求錯。

第三次的話，就是注意一下評測機系統的System.exit返回值必須爲0，否則就會RUNTIME_ERROR就是了。其實在中測的時候就已經發現了這個問題，可是還有一個System.exit(-1)沒有改掉，說白了仍是本身不細心。

分析本身發現別人程序bug所採用的策略

頭兩次由於Bug都分在了C組，用黑盒盲測的方法就能發現許多BUG（並且都是一些各類各樣無厘頭的WRONG FORMAT類問題，技術含量真心低），第三次也無意投入太多時間用來找BUG，因此沒什麼可談的。

值得一提的是，有時採用代碼評審的方式，可以從代碼中直接找出BUG的存在，這個方法在之後處理多線程程序時會起到很重要的做用。

Applying Creational Pattern

若是沒錯的話應該是用了一個叫什麼工廠模式的東西，雖然並非有意識地在用，寫的時候也並不知道這個東西。不過設計模式這個東西真的挺有用的，建議課上多講一些。