一、程式結構分析
第一次作業
第一次作業并不難，但感覺對于面對對象不是特别了解，是以很多地方還是沿用了面向過程的方法，将很多過程都放在一個方法裡，一個類裡，導緻盡管作業很簡單依然有飄紅的點。
第一次的架構很簡單，寫了一個處理表達式的類，一個正規表達式類，一個項類和表達式類，表達式類用
ArrayList
容器存儲項。第一次作業的性能分也較容易獲得，隻需考慮合并和開頭+号的省略即可。
第二次作業
第二次作業相對而言難度就提高了，第一時間都沒有思路。第一次作業式隻寫了一種項，就是帶系數的幂函數，第二次作業發現不得不分開，是以分為了常數，cos，sin，幂函數因子，每個項都是這4種因子組合而成，是以專門寫了一個
TermUnion
類專門管理每個由四種因子組合成的項。
這次作業還需要考慮WF，但這次作業的因為不考慮空格的WF，是以直接用正規表達式判斷是否符合格式即可。
第二次作業的合并相對困難了很多，是以專門寫了一個類
TermFun
進行項之間的合并，但關于三角函數的最優化簡較為複雜，是以我寫的方法也很臃腫，但關于三角函數的化簡有時候還是無法做到最優。
第三次作業
第三次作業難度較高，一開始都不知道如何入手。其實最主要的問題還是前兩次作業的構造不适合疊代開發，寫法很不成熟，導緻第三次作業的工作量大大增加。第三次作業我删去了原來的大部分類，重寫了一個Item父類，各種因子都繼承自Item類，Item類包含求導方法，求導後結果的字元串形式（cos，sin，還有表達式因子這些可以嵌套的因子中還包含了求導後結果的List形式）。
另外寫了一個Sympify類，用來化簡表達式同時将表達式轉化為List形式，多項式類Polynomial中有方法可以根據多項式的List形式得到其最簡的字元串形式。PolyControl類式用來管理多項式的，并含有對整個表達式的求導方法。
是以總體思路就是先将表達式進行去空格的預處理，再通過Sympify類逐層遞歸得到整個表達式的List形式，然後通過PolyControl類對整個表達式進行求導得到List形式和字元串形式的求導結果，然後輸出。
關于WF的處理是再去空格之前進行關于空格WF的判斷，然後再逐層遞歸過程中再進行格式判斷。另外關于表達式的合并以及Sympify類寫的較為臃腫，複雜度較高，關于代碼架構還有很大的優化空間。
二、BUG分析。
第一次作業和第二次作業都沒有出現BUG，第三次作業由于大量時間花在了化簡上，導緻沒有全面的對WF進行測試，是以最後強測有三個WF的點沒有判出來。互測也有個關于表達式因子的BUG，表達式因子是不能有指數的，而我錯誤的将兩個相同的表達式因子相乘給合并了，導緻出現了BUG。這些BUG其實不難發現，主要原因還是由于太過追求性能分導緻沒有仔細去測試這些細節。
三、互測政策。
主要用評測機進行大規模資料測試，如果有BUG就回報。第一次作業用評測機沒有發現任何BUG，但确實有一位同學的代碼是存在BUG的，由于我對指導書的表達式格式的了解不夠透徹，導緻沒有發現這個BUG，第二、第三次都用評測機發現了一些BUG。
對于那些結構清晰的代碼，會認真閱讀并能從其中學到一些東西，而對于那些結構混亂且沒有注釋的，還是放棄看了。
很多BUG都是邊界資料造成的，是以每次還另外自己寫了一些評測機難以随機到的邊界資料，用來對自己的程式進行測試和進行互測。
四、應用建立對象模式重構。
這個單元的作業其實都可以用工廠模式來進行對象建立，可以先用正則來比對出項，再将項的字元串扔給工廠，由工廠内部來構造對應的項，這樣既很好的降低了耦合度，也可以讓代碼結構更加清晰。
五、對比和心得體會。
對于面向對象這一點的認知還是不夠清晰，代碼的耦合度過高，不符合高内聚低耦合的原則，結構也不是很清晰，類與類之間的關系很混亂。代碼的可疊代性太差，每次作業都隻考慮到了本次作業的構造，導緻下次作業不得不進行大幅度的重構。經過這三次作業，雖然在慢慢的進步，但還是有很多缺陷。不過對于面向對象這一思想總算有了一定的了解，對于以後作業的架構也有了一點想法。在今後的作業中，要充分考慮到可疊代性以及高内聚低耦合的原則。