【OO多項式求導做業總結】

 OO-Part1-多項式求導

總的來講，我對本身這三次做業的完成狀況並不滿意，首先，我仍然保持着C語言面向過程式的編碼風格，這也致使我未能按時完成第三次做業，在此深入反省；其次，我未能意識到互測環節的重要性，正如討論區大佬所說，「互測不是讓你爲了發現別人的bug而互測，而是爲了讓你在發現別人bug的同時，發現本身的bug並進行相應的修改，得以提高」；再次，心態和情緒管理不到位。在面對第三次做業「強迫」使用面向對象的時候，我未能及時尋找資料，而是怨聲載道，自怨自艾，現在想來才意識到這是弱者才應有的態度。但願我能從前三次做業中發現並總結本身的問題，在後續的挑戰中迎難而上，抵達到崑崙課程的頂峯。

第一次做業：簡單多項式導函數

用UML工具生成的類圖：

 

 

因爲當時沒有及時總結面向過程式編程的弊端，我沒有合理的劃分類，更不用說了繼承和接口的使用了。

如今想一想，其實冪函數自己就是一種因子，不必根據其結構劃分五個求導方法，這種設計不知足高內聚低耦合的思想。而且，在類內沒有對數據進行封裝和隱藏，這也顯然不符合OOP的思想。

公測

公測沒有出現意外，筆者的程序在公測階段沒有出現除性能分之外的錯誤。

互測

總共被hack9次，類型基本上是格式判斷的問題，對正則表達式進行了簡單的修改後，順利完成了合併修復。

hack屋內全部人共計18次，發現bug的主要問題在：對格式的判斷和對單個數字的求導的處理不正確。

思考與感想

第一次做業的算法和工程方面的要求都不高，因此用面向過程的思惟也苟了過來。。。但其中發現了本身和同窗的一些共性的bug，也能夠說是不夠良好的編程風格：

一、試圖用一個龐大的正則表達式判斷格式，在瀏覽昂神的blog以後發現，我對正則表達式的使用存在必定的誤解。正則表達式更多的用於相對簡單且沒有複雜的重複和嵌套的一些的模式匹配，以及其內部關鍵位置信息的提取。因此在第三次做

 

業中，很完美的限制了正則表達式的使用。

二、一個值得提高的點是關於數據容器的使用，數據的存儲也是Java面向對象設計中的一個重要環節，是否能高效的組織數據極大程度上決定了一個程序是否能跑下去. 直接使用傳統的固定大小數據容器顯然沒法知足需求,因此, 天然就想到了利用Arraylist, Hashmap之類的序列類容器.

第二次做業

在第一次做業的基礎之上添加了三角函數因子

類圖

 

在第二次做業中,我依舊沒有領悟到面向對象的核心思想, 由於經過觀察和必定的數學計算,我發現了全部的正確輸入均可以轉化爲以下所示的統一形式.

coeff*x^a*sin(x)^b*cos(x)^c 

那麼利用三個指數做爲hashmap的索引，係數做爲Hshmap的值組織數據既能夠高效的組織數據，又能輕鬆的進行同類項合併。

不足：

沒有體現面向對象的思想，思惟仍然束縛於面向過程式的編程，主要體如今：利用多個函數組合處理輸入的多項式，設法將其化簡爲標準形式。

公測：

1.因爲優化的問題，致使原先已經完成的數據處理出現了bug

2.正則表達式的使用出現了bug，【】內對字符的引用不該添加單引號。

思考與感想：

第二次做業相對於第一次做業難度上的遞增較大，可是因爲發現了三元組這一奇技淫巧，致使面向對象的思想仍是沒能在腦海中創建起來，這是在寫第二次做業中較爲遺憾的地方，因此筆者在第三次做業中遇到了極大的困難。

第三次做業

這是什麼鬼？這怎麼寫得出來？又要重構？！這設計根本沒法實現啊？！

在拿到指導書左思右想了一天以後，我想到了利用分類的作法，即：將表達式分爲【加減|乘|嵌套】三類，去完成此次做業；但開始碼字伊始，就以爲方案不可行，由於正則表達式不能嵌套定義，因此沒法匹配出我設計中想要的信息，當時時間已經到了週日晚上，個人初步架構都沒有創建起來，內心十分崩潰。

最終令我極爲難以接受的失敗終於降臨了，我miss了第三次做業的ddl。

過後想一想，感受程序設計這活，一開始是不可能找到完美的解決方案的（最優解），然而此次做業的最優解也是存在的，即以下圖所示。（雖然沒有在ddl內完成做業，也不甘心被此次做業戰勝）。

 JAVA設計模式——工廠模式

建立型模式是三大設計模式（建立型模式、結構型模式、工廠型模式）之一，另外兩種爲結構型模式與行爲型模式。建立型模式一共分爲五種模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。在第三次做業中主要採用了工廠模式，即：因子類這一工廠，能夠生產出不一樣類型的因子「產品」，每種產品保留了因子類的共性，同時也有自身的特性，如：求導方式，判別模式……

思考與感想：

2.對OO做業新的認識：

除了指導書的各類官方要求：講究代碼風格，設計層次以外，我還想談談OO做業的挑戰性。

挑戰點一：編寫程序的挑戰。解決從無到有的問題是咱們首先應該考慮的問題，任何一次OO做業都不可能一蹴而就，設想程序沒法站立起來的狀況下，還期望它能跑嗎？因此應一步一步地由獨立的單元搭建起整個工程，而不是成天對着設計紙上那幾條算式瘋狂抖腿抓頭髮…

挑戰點二：要充分明確指導書的需求，掌握其中的重要細節和提示。這對後續的bug調試和互測中程序的防護十分重要。在第一節OO課上老師就強調過「道路千萬條，條條皆安全」。在編寫程序的時候就要注意到哪些是薄弱環節，如何增強它，如何保證它的魯棒性，不會輕易被攻破。

挑戰點三：OO做業不只是對面向對象能力的考查，也是對一我的性情的考驗。在面對困難的時候，失敗者老是設想「若是我作不出來的後果」，因而終日惶惶恐恐，什麼也寫不出來；成功者想的倒是「只要我認真去作，就必定能完成」。在如此短期內完成如此龐大的工程實屬不易，保持一顆積極向上的心態，多構思，多實習，在不斷嘗試中提高本身的OO水平。

2.對OO新的認識：

通過第三次做業的挫折，彷佛對面向對象這個概念有了新的認識，借用何大佬在交流課上所提出的問題，「如何造一架飛機」？典型的面向過程思惟是：先設計圖紙，而後一股腦的把整架飛機搭建出來，顯然這是不可能完成的事情；然而若是用面向對象的思想，將其分而治之，先造機翼，再建機艙，再建控制檯，起落架……最後把各類零件整合到一塊兒，組成一架飛機。具體到第三次做業來講，面向過程的思惟是一次性處理全部的輸入數據，判斷格式，構建數據容器存儲數據，求導，相加，輸出……繁冗的細節決定了面向過程思想必然不能解決問題；然而用面向對象的思想就應該是，因子分類：sin/cos/power/num/expre五個類，共同繼承一個抽象類factor；項是由因子組成的鏈表；表達式當作是項組成的列表。如此層層遞進，數據的存儲將變得十分簡便。

面向對象的編程思想不是一朝一夕能實現的，須要不斷的動手嘗試，閱讀高質量的優秀代碼，才能不斷的提高。但願與我有一樣問題的同窗能再接再勵，利用此次寫博客的時間好好反思，好好整理心情，該出去踏青的時間就不要在學校裏苦幹寫不完的做業，這樣其實效率很低（我的親測）。一次挫折並不影響崑崙歷練的成功，不要被困難擊退，重整旗鼓，迎難而上。