雖說後一次作業是對前一次作業的擴充，然而由於我不太熟悉面對物件程式設計的思想，程式的可擴充性極差，致使三次作業三種架構，異常愚蠢。
· 設計思路
受上機實驗**啟發，用兩個數——係數和指數來表示一項，用項組成的表來表示項之間的加法關係。通過對表示式符號的簡化，得到了更符合一般形式的輸入，但背離了題目中的構造思路，為第三次作業wf判斷的崩潰埋下伏筆。
主類包管一切，從輸入的處理到表示式的構造到求導一條龍大包乾。表示式構造的邏輯是搜尋下乙個因子→因子係數相乘指數相加→檢索到項之間的正負號時將總係數和指數構造成一項，併入表示式表。求導的邏輯是直接對映，對每一項係數乘指數，指數減一。輸出的邏輯是每一項輸出本身的字串，表示式將項字串之間用符號連線，再歸總輸出。
· 設計思路
新增了三角函式因子和表示式因子。受前一次作業影響，本次作業的完成思路可謂奇葩。資料結構上為了將第一次作業中的僅由兩個數組成的乙個冪函式項擴充為包括係數、sin、cos、冪函式的項，我大腦短路，居然把原先的項整成鍊錶，再加上標識位來區分每一項是什麼型別的。（事實上在原有基礎上增添兩個變數儲存sin和cos的係數就夠了， 而且標識位事實上沒有起到任何作用，因為構造項的時候四種因子間有明確的順序關係）。這樣做加大了合併同類項的難度，還莫名其妙多出了許多容易出bug的點。這樣清奇的資料架構使我現在回想起來仍感到無比愚蠢，不僅沒有應用到物件導向程式設計的思想，甚至連基礎的資料結構都一塌糊塗，**上為了構造出一項，甚至要重複寫四遍類似的**。
為了處理表示式因子的輸入，我把原先堆積在主類的輸入處理邏輯獨立出來成了乙個expressionsearcher類，使得遇到表示式因子時可以簡單遞迴處理。但此類仍然留下了第一次作業粗糙的設計，使得難以獨立出具體的尋找因子方法，為wf崩潰埋下伏筆。由於資料結構沒有留下表示式因子的位置，我採用多項式乘法把表示式因子和其它因子的乘積計算出來成為新的表示式，再簡單把新表示式和原表示式合併。（且由於前文伏筆，我沒有寫合併同類項的方法）
由於表示式全被化為了簡單的c*x**e1*sinx**e2*cos**e3形式，我採用類似第一次作業的簡單的對映來完成求導(這估計也是我的架構下唯一的優點了，然而又導致了第三次作業的噩夢)，一項求導得三項，再合併這三項入求導結果表示式(由於資料結構問題，這裡寫了大量重複的**)。
· 設計思路
新增了三角函式括號內巢狀因子和格式檢查。
在這一次作業我大改特改，總算讓成品有了面對物件程式設計的感覺了。針對常數因子、sincos因子、冪函式因子、表示式因子我分別建立了類，並且為其設立了可導介面。其中三角函式巢狀因子我的實現方法比較彆扭。由於沒有獨立出單純的getfactor方法，我的操作是把括號內因子當作乙個表示式，再把表示式括起來成為表示式因子。我為因子設立了下一因子指標，以模擬乘法的鏈。求導方法是鏈式求導，對一項求導的結果是該項的第乙個因子的導因子乘以這一項的下一因子加上第乙個因子乘以下一因子的導因子。求導過程中會有多項式出現，我直接把多項式括起來成為表示式因子。固然從邏輯上比較清楚，但效能上不忍直視。結果往往帶有巨量的括號和大量無意義的項和因子。
格式檢查上，由於前面作業打下的「基礎」，我無力再重構，只好加入各種各樣的判斷語句來實現。具體上就是對輸入預處理時我處理了連續的正負號和所有的空格符，所以我在格式處理前針對這兩點寫了判斷；在表示式的解析時，我通過匹配的字元數是否等於輸入的長度來判斷是否每乙個字元都是有意義的；在三角函式內的因子裡，由於我異想天開的處理，致使我還要專門判斷這個因子是否是合法因子。
這次作業讓我體會到了物件導向程式設計的感覺，遺憾的是由於時間緊張，我沒能在時限前完成提交，錯失了一次機會。
事實上第2、3次作業的複雜度都是隨項內的因子數量指數型上公升的。事實上理論複雜度也是指數型的，但我對於結果缺乏基本的優化，致使一些時候產生了天量的輸出長度。
第一次作業強測及互測均沒有測出bug；第二次作業由於設計的失敗，導致產生了難以發覺的符號錯誤問題，使得我強測幾乎全過卻在互測中被整得很慘。
根本找不到別人的bug，組除我佬。
前面的**寫得很屎，導致後面的**堆在屎山上。在時間緊張的條件下，我沒有餘力完成進一步的優化，使後面兩次作業積重難返。面對物件程式設計的思想非常有趣且必要，可惜前面兩次的作業完全是縫合怪，「四不像」。良好的架構是乙個發展的專案的必要條件，否則後面隨時會崩潰。**沒能做到「高內聚低耦合」，（主要是在表示式分析部分）；乙個方法寫上百行卻沒有拆分成功能更加明晰的小組件，使得有新的需求時又要造重複的輪子，可讀性也大大降低。oo這門課我還得多學。
OO第一單元作業總結
1.第一次作業 第一次作業時我還沒有建造者模式這種概念，因此是把字串處理的工作交給expr類來處理，在expr類中呼叫term的構造方法，並將term的係數與指數存放在expr的容器中。類圖如下 結構比較的簡單 下面是複雜度分析 可以看出，在expr的求導操作中複雜度較高，這是因為我第一次作業中求導...
OO第一單元總結
由以上類圖，大體分析本次作業程式設計思路如下 2 根據資料度量分析程式結構 那麼根據以上引數含義，分析本次作業 發現，有三個方法的這三個複雜度較高，分別是ploynomial.getpoly readterm.getnum readterm.getterm 所以可以知道本次程式分別在讀入操作和獲得表...
OO第一單元總結
第一單元的作業為多項式求導，在迭代作業中學習了 物件特性 oo構造機制和層次化設計，在bug互測環節也學習到很多巧妙的設計。設計了三個類 term derivative和reportexit，分別處理項 求導和報錯退出，如今回頭看有很多設計不合理的地方，例如在term構造方法中直接解析表示式並設定成...