一、基于度量對(duì)程序結(jié)構(gòu)的分析

1. 第一次作業(yè)

1.1 基于類的分析的度量

首先，基于類的屬性個(gè)數(shù)，方法個(gè)數(shù)，每個(gè)方法的規(guī)模，每個(gè)方法的控制分支數(shù)目，類總代碼規(guī)模等特征對(duì)本次作業(yè)的結(jié)構(gòu)進(jìn)行分析。

1.2 基于類間內(nèi)聚和耦合的度量

我使用了MetricsReloaded插件來對(duì)代碼的復(fù)雜度進(jìn)行了分析。

還有對(duì)于方法的復(fù)雜度分析由于篇幅原因沒有貼出來，主要的指標(biāo)為ev,iv,v三個(gè)指標(biāo)，分別代表基本復(fù)雜度、模塊設(shè)計(jì)復(fù)雜度以及模塊判定結(jié)構(gòu)復(fù)雜度，ev大代表代碼非結(jié)構(gòu)化程度高，難以模塊化和維護(hù)。iv大代表模塊間耦合度高，模塊間難以隔離與復(fù)用，v大表示代碼獨(dú)立路徑條數(shù)多，難于測(cè)試和維護(hù)。在做面向?qū)ο蠖攘繒r(shí)，我們經(jīng)常采用ck度量(Chidamber Kemerer)來度量耦合，內(nèi)聚，封裝等等特征。上表中wmc代表的是類的方法權(quán)重，表示一個(gè)類中所有方法的復(fù)雜度之和。顯然越大說明越復(fù)雜。

1.3 UML圖及結(jié)構(gòu)點(diǎn)評(píng)

由于是第一次作業(yè)，因此對(duì)于面向?qū)ο蟮乃枷脒€不是特別熟悉，我這次將main類與Poly類寫到了一起，其實(shí)應(yīng)該分離，一個(gè)多項(xiàng)式的類，一個(gè)項(xiàng)的類，一個(gè)main入口類。整體來講結(jié)構(gòu)不是很好，而且有兩個(gè)比較長(zhǎng)的方法同時(shí)分支較多，同時(shí)也就造成了它們的獨(dú)立路徑數(shù)較多，模塊復(fù)雜度較高。

2. 第二次作業(yè)

2.1 基于類的分析的度量

2.2 基于類間內(nèi)聚和耦合的度量

我的高復(fù)雜度方法體現(xiàn)在輸入處理，輸出處理以及化簡(jiǎn)上，這次作業(yè)如何有效的化簡(jiǎn)是一個(gè)難點(diǎn)。

2.3 UML圖及結(jié)構(gòu)點(diǎn)評(píng)

本次作業(yè)的設(shè)計(jì)較為體現(xiàn)了面向?qū)ο蟮乃枷?，設(shè)計(jì)了一個(gè)main入口類，多項(xiàng)式類，項(xiàng)類，因子類，以及其中由于因子是由底數(shù)和指數(shù)組成的，而指數(shù)又有多種形式，故設(shè)計(jì)了一個(gè)底數(shù)的抽象類base，將常數(shù)類const,冪函數(shù)類power，三角函數(shù)類triangle作為了base的子類，這樣就可以將一個(gè)多項(xiàng)式一點(diǎn)點(diǎn)解析成項(xiàng)，因子，底數(shù)，指數(shù)等等。同時(shí)，由于每一個(gè)類都有共同的特點(diǎn)就是可求導(dǎo)，因此我設(shè)計(jì)了一個(gè)求導(dǎo)的接口Derivable,所有的類都實(shí)現(xiàn)了這個(gè)接口，這符合了java面向接口編程的思想，同時(shí)也提升了代碼的規(guī)范性。

3. 第三次作業(yè)

3.1 基于類的分析的度量

3.2 基于類間內(nèi)聚和耦合的度量

發(fā)現(xiàn)我的高復(fù)雜度的方法全部都是對(duì)于輸入處理上，由此可見我的輸入處理的不太好，寫的十分面向過程且十分容易出錯(cuò)。

3.3 UML圖及結(jié)構(gòu)點(diǎn)評(píng)

本次作業(yè)的架構(gòu)和上一次作業(yè)是完全一致的，因?yàn)樯洗巫鳂I(yè)時(shí)我就考慮到了程序可擴(kuò)展性的特點(diǎn)。然而本次作業(yè)在加了表達(dá)式因子和嵌套因子后顯得這個(gè)架構(gòu)有一些問題。求導(dǎo)部分利用遞歸向下求導(dǎo)的方式倒是不難實(shí)現(xiàn)，此次作業(yè)最難的輸入部分我處理的不是很好。這次輸入的難點(diǎn)主要是出現(xiàn)了表達(dá)式因子和嵌套，我們?nèi)绾斡谜齽t表達(dá)式來正確的識(shí)別和解析。我的想法是先找到所有非三角函數(shù)括號(hào)中最內(nèi)層的括號(hào)，將其解析為一個(gè)多項(xiàng)式，這時(shí)再解析出該多項(xiàng)式內(nèi)部的三角函數(shù)，把三角函數(shù)括號(hào)中嵌套的多項(xiàng)式因子解析到三角函數(shù)的屬性中去，重復(fù)這個(gè)步驟直到?jīng)]有括號(hào)為止。整個(gè)過程雖然可以實(shí)現(xiàn)但是十分復(fù)雜，十分面向過程且會(huì)有多分支，行數(shù)非常多的方法，復(fù)雜的正則表達(dá)式的存在。后來在討論課上聽說的用工廠模式或一個(gè)parser的類可以更好的實(shí)現(xiàn)該輸入解析過程，parser類里面分別有對(duì)poly,item,factor的解析方法，高內(nèi)聚低耦合避免了一大串if-else的出現(xiàn)。

二、Bug分析

1. 第一次作業(yè)

第一次作業(yè)我的強(qiáng)測(cè)沒有出現(xiàn)WA的情況，但是被hack了12次(2同質(zhì))，分別是\\s+匹配到\t和空格外的字符的情況、以及直接輸入空格程序crash的情況，程序crash的原因是我在得到字符串之后直接進(jìn)行了input.trim()操作，導(dǎo)致輸入input變?yōu)榭沾绦騝rash，有兩種更改方式，一種是直接把main方法里面的所有內(nèi)容用try-catch保住，確保程序不會(huì)出現(xiàn)crash(這也是我后面兩次作業(yè)的寫法)，另一種方法是在trim()后面再判斷一次串是否為空。對(duì)于另外一個(gè)bug，我的正則里面寫的是[ \\t]*然而還是出現(xiàn)了bug，這與我程序的設(shè)計(jì)結(jié)構(gòu)密切相關(guān)，因?yàn)槲以賱倓傋x入input的時(shí)候就用trim()去掉了兩邊的空白符，這樣導(dǎo)致輸入字符串兩邊的\v和\f無法有效的識(shí)別WF，造成了bug的出現(xiàn)。我的修改方式是先看所有的輸入字符是否有非法字符，如果有的話直接輸出WF即可。

2. 第二次作業(yè)

第一次作業(yè)我的強(qiáng)測(cè)沒有出現(xiàn)WA的情況，但是也被hack了3次(2同質(zhì))，分別是在輸入符號(hào)處理中的if表達(dá)式中的||手誤寫成了&&，和對(duì)于輸入錯(cuò)誤的匹配沒有識(shí)別出WF。仔細(xì)想想，這與我的設(shè)計(jì)結(jié)構(gòu)也有著千絲萬縷的聯(lián)系。我對(duì)于輸入的處理是在去掉了輸入兩邊的空白字符后依據(jù)此時(shí)input.CharAt(0)來確定在前面添加"+"或者"+0",然而我沒考慮到*x若在前面"+0"會(huì)造成本來是WF的數(shù)據(jù)變成合法，因此導(dǎo)致了bug。另外一個(gè)bug就是典型的一大段if-else造成的鍵盤誤操作，這也體現(xiàn)了減少分支數(shù)量降低代碼復(fù)雜度的必要性。

3. 第三次作業(yè)

第三次作業(yè)我的強(qiáng)測(cè)WA兩個(gè)點(diǎn)，被hack了10次(強(qiáng)互測(cè)加起來2同質(zhì))，分別是輸入匹配時(shí)正則表達(dá)式少了一個(gè)[ \\t]*造成的有空格導(dǎo)致不匹配以及一個(gè)符號(hào)出現(xiàn)了問題。這兩個(gè)問題的產(chǎn)生就與我的設(shè)計(jì)非常密切的相關(guān)了。我寫了4個(gè)正則，其中最大的正則有6行，如此長(zhǎng)的正則難免會(huì)不小心失誤，寫小正則把問題分開分析是避免這類錯(cuò)誤的一個(gè)很好的方式。而另外一個(gè)符號(hào)錯(cuò)誤則完全是由于我的輸入寫得太過復(fù)雜，括號(hào)來回匹配的邏輯，比如解析一個(gè)item，會(huì)返回一個(gè)poly.解析一個(gè)factor也會(huì)返回poly，而每個(gè)item都有其固定的符號(hào),這次Bug的出現(xiàn)就是因?yàn)樵诮馕鰅tem返回poly的時(shí)候沒有考慮原來item的符號(hào)，而默認(rèn)"+"造成了錯(cuò)誤。由此可見，面向?qū)ο蟮脑O(shè)計(jì)模式，封裝的好處就是減少耦合，減少出錯(cuò)點(diǎn)。

三、Hack策略

1. WF

前兩次作業(yè)錯(cuò)誤主要集中在WF上，這時(shí)候就可以手動(dòng)設(shè)計(jì)測(cè)試樣例，比如全空格，空串，只輸入常數(shù)，輸入x^0，0*x，si n(x),sin   ( x    )，+++1，++ 1，\f\v，BigInteger,爆棧,......等等，因?yàn)榍皟纱巫鳂I(yè)正確性的實(shí)現(xiàn)上并不難，主要大家的出錯(cuò)點(diǎn)在對(duì)WF的處理上，因此我的這種策略有效性也很高，前兩次作業(yè)共提交7個(gè)測(cè)試樣例hack18人次。

2. 正確性問題

第三次作業(yè)強(qiáng)調(diào)正確性的問題，我也從正確性的問題入手，具體方法就是對(duì)于指導(dǎo)書上對(duì)本次實(shí)驗(yàn)要求的所有功能，先分別構(gòu)造測(cè)試數(shù)據(jù)，在將各種模式組合起來，比如sin()里面有表達(dá)式，里面還有嵌套的sin()，再加一些項(xiàng)乘起來之類的。覆蓋所有的情況覆蓋所有的功能就能找出bug。由于第三次作業(yè)大家基本都沒怎么優(yōu)化，所以直接看輸出結(jié)果很難看出正誤，因此可以把每位被測(cè)者的輸出結(jié)果賦上一個(gè)x值(比如x=1.1)比較不同被測(cè)者輸出結(jié)果的值是否相等，若不相等顯然是出現(xiàn)了問題。

3. 根據(jù)程序找bug

這種方法難度較大，主要原因是部分代碼可讀性較差，結(jié)構(gòu)不清晰，等等。當(dāng)然如果能看懂對(duì)方程序的話肯定是更容易從根源處找到bug。通過白盒測(cè)試，對(duì)復(fù)雜的類進(jìn)行單元測(cè)試來尋找bug。

四、Applying Creational Pattern

1. 工廠模式

工廠模式(Factory Pattern)是Java中最常用的設(shè)計(jì)模式之一,這種類型的設(shè)計(jì)模式屬于創(chuàng)建型模式，它提供了一種創(chuàng)建對(duì)象的最佳方式。在工廠模式中，我們?cè)趧?chuàng)建對(duì)象時(shí)不會(huì)對(duì)客戶端暴露創(chuàng)建邏輯，并且是通過使用一個(gè)共同的接口來指向新創(chuàng)建的對(duì)象。因此，對(duì)于本次作業(yè)可以使用工廠模式來創(chuàng)建表達(dá)式，項(xiàng)，因子，我們只需定義一個(gè)創(chuàng)建對(duì)象的接口，讓實(shí)現(xiàn)了該接口的子類自己決定實(shí)例化哪一個(gè)工廠類。在我們明確地計(jì)劃不同條件下創(chuàng)建不同實(shí)例時(shí)，工廠模式將十分管用。

2. 抽象工廠

抽象工廠模式(Abstract Factory Pattern)是圍繞一個(gè)超級(jí)工廠創(chuàng)建其他工廠。超級(jí)工廠又稱為其他工廠的工廠,在抽象工廠模式中，接口是負(fù)責(zé)創(chuàng)建一個(gè)相關(guān)對(duì)象的工廠，不需要顯式指定它們的類。每個(gè)生成的工廠都能按照工廠模式提供對(duì)象。系統(tǒng)的產(chǎn)品有多于一個(gè)的產(chǎn)品族，而系統(tǒng)只消費(fèi)其中某一族的產(chǎn)品時(shí)，可以使用抽象工廠作為所有工廠的抽象父類，這樣我們就不用花費(fèi)時(shí)間在選擇接口上了。

五、總結(jié)與展望

1. 總結(jié)

4周時(shí)間過去了，OO也過去了第一單元，早就聽說了OO的恐怖，如今也確實(shí)是體驗(yàn)了一番?？傮w來講第一單元的學(xué)習(xí)還算滿意，測(cè)試方面仍需加強(qiáng)，另外就是面向?qū)ο蟮乃枷脒€需不斷的培養(yǎng)。第一單元其實(shí)主要還是java的入門，幫助我們更加熟悉java的使用。還有就是感覺今年的OO確實(shí)感覺要比往屆好了不少，公測(cè)分占主要的情況下大體上保證了課程的公平，分ABC組互測(cè)也避免了一些悲慘的情況，總體來講OO課在不斷變好，在此感謝助教和老師的付出！

2. 展望

前路漫漫，道阻且長(zhǎng)。后面還有多線程等等很難的知識(shí)和作業(yè)在等著我們，希望我們能繼續(xù)努力，在本學(xué)期結(jié)束時(shí)能真正有很大的收獲。