1.第一次作業
第一次作業時我還沒有建造者模式這種概念，因此是把字串處理的工作交給expr類來處理，在expr類中呼叫term的構造方法，並將term的係數與指數存放在expr的容器中。
類圖如下：
結構比較的簡單
下面是複雜度分析：
可以看出，在expr的求導操作中複雜度較高，這是因為我第一次作業中求導時沒有用容器來存放求導後的項，而是直接轉換成字串，導致複雜度飆公升。下次應該注意。
2.第二次作業
第二次作業抽象出了項和因子的概念，同時也照貓畫虎地引入了因子的父類。這次引入了parser類，集中進行物件的建立，把表示式、項、因子的耦合度降低。在初稿中因為聽到了第三次作業的一些訊息，所以寫了乙個擴充套件性比較好的版本。不過後來為了保險起見，還是採用了正規化的方法，即在項中存放係數、冪函式因子、三角函式因子。
類圖如下：
結構還算清晰。
複雜度分析：（只摘取了複雜度標紅的部分）
可以看到，複雜度較高的部分集中在字串處理上。ev較高，主要原因是沒有在建立的時候引入工廠模式，把所有的不同因子的建立寫在乙個函式當中了。這是可以改進的地方。
3.第三次作業
第三次作業難度較大。因為在第二次作業寫完之後立即投入到了第三次的企劃當中，因此時間一開始還比較充裕，初稿也是進行了很多的優化，挑戰了自己。但是後來發現自己的乙個嚴重的bug，那就是沒有進行轉殖，修復之後中測直接tle乙個。最後只能忍痛割愛，放棄了絕大部分的優化，可能還是功力不夠吧。
結構上與第一次差不多，最主要的區別是第三次作業中有些因子的內部存放的是乙個表示式，求導的時候進行遞迴的求解。第三次的難點對我來說還是在parser上面。
類圖如下：
和第二次很相近。
複雜度如下：
這次標紅的地方更多了。實際上，原來優化版本的複雜度比這個還要高。問題還是出在parse上面。
1.自己的bug
這一單元整體表現都不是很好。在第一次作業中，雖然並不是超長正規表示式匹配的，但是卻寫了乙個超長的正則（後來加了個注釋符就解決了），導致強測tle乙個，在互測中也是在這裡被輸出；第二次作業也很可笑，明明放棄了很多優化，最後還是想占個小便宜，在輸出的時候將x2替換成x*x，結果就出現了x241變成x*x41的尷尬局面，互測時也是被精準發現；第三次更加難受，因為在最後乙個小時內發現了bug,（就是在sin與cos內部對是否是表示式因子進行判斷的地方），然後急速debug，結果引入了乙個更大的bug：對於sin或者cos內部的兩層及以上的括號，我均未返回表示式因子，返回的是乙個null，可笑的是竟然苟過了中測，甚至竟然進入了互測（當然互測的時候被捅成了篩子，幾乎隨便寫乙個複雜一點的樣例都能刀中我），強測更是直接掛掉5個。可以看到，我每次任務均沒有做到極致，每次均是因為一些這樣那樣的原因而無法全部通過。教訓就是以後每乙個版本均要在本地做足測試，同時，一定要把握住每乙個細節，不能讓差一點點成為乙個壞習慣。
2.他人的bug
找他人的bug主要來自兩方面，第一是用python寫了個隨機生成資料的程式（但是完整的評測機還是不會寫），通過這種方法找到了些許bug；第二種方法是閱讀**。其實os實驗課的主要內容也是閱讀**，閱讀**還是很有趣的，很像解謎，遇到好的**還能拜讀（如果不是一味地想找bug的話）。前兩次作業中我每次均挑了乙份較好的**進行了閱讀，然後找到了bug，第三次因為心裡實在五味雜陳、沒有心情所以就沒有很積極地參與到聖杯戰爭當中。以後為了閱讀到更好的**應該把自身的段位提高。
目前學到的建立模式只有工廠模式。在這三次作業當中，後兩次作業的parser可用說是有了些建立模式的影子，但是更好的解決辦法是將建立物件的部分再分出來，用乙個工廠來建立不同的因子。具體做法是當一種matcher匹配到後，找到工廠宣告需要哪種的因子。這麼做應該可以比較好地降低耦合度。
與自身對比的話，確實是在進步，但是每一次都不能做到沒有瑕疵也是頑疾；與他人對比的話，自己還是太菜了。面對這種菜一是要產生動力，二是不要被搞壞了心態，盡力去做就好了。
心得來講，通過這三次作業我算是入了乙個門，同時也意識到了差距與難點所在。雖然分數不是很理想，但是也可以稱得上是乙個良好的開端。還有一點很深的體會是：不要過分地糾結於分數，每次的目標應該是寫出更好的**，這個目標達到了，分數只是一種認可形式。另外在互測的時候，不要被搞壞了心態，糟蹋一整個週末。
oo第一單元作業總結
雖說後一次作業是對前一次作業的擴充，然而由於我不太熟悉面對物件程式設計的思想，程式的可擴充性極差，致使三次作業三種架構，異常愚蠢。設計思路 受上機實驗 啟發，用兩個數 係數和指數來表示一項，用項組成的表來表示項之間的加法關係。通過對表示式符號的簡化，得到了更符合一般形式的輸入，但背離了題目中的構造思...
OO第一單元總結
由以上類圖，大體分析本次作業程式設計思路如下 2 根據資料度量分析程式結構 那麼根據以上引數含義，分析本次作業 發現，有三個方法的這三個複雜度較高，分別是ploynomial.getpoly readterm.getnum readterm.getterm 所以可以知道本次程式分別在讀入操作和獲得表...
OO第一單元總結
第一單元的作業為多項式求導，在迭代作業中學習了 物件特性 oo構造機制和層次化設計，在bug互測環節也學習到很多巧妙的設計。設計了三個類 term derivative和reportexit，分別處理項 求導和報錯退出，如今回頭看有很多設計不合理的地方，例如在term構造方法中直接解析表示式並設定成...