一、對(duì)面向?qū)ο蟮睦斫?/p>

　　有位同學(xué)給java的面向?qū)ο笞隽艘粋€(gè)形象生動(dòng)的類比，我覺得很有道理，大概按我的理解如下：

• • 結(jié)構(gòu)的形成
    看圖之前，我們要先明白，世界上是先有了實(shí)體，才有了一步步抽象至以上的體系結(jié)構(gòu)，當(dāng)然也未必是自底向上逐步抽象，也許在最初的認(rèn)識(shí)體系中，只有故宮里的植物C、植物、和存在，或許迎客松A和蒹葭B都是植物的對(duì)象，在之后的認(rèn)識(shí)中逐步向上抽象出生物，向下細(xì)分為樹和草等等。
    但無論如何，所有的抽象類都是我們從實(shí)體中歸納總結(jié)出的，不是憑空產(chǎn)生的。　　　
    在真實(shí)的程序設(shè)計(jì)中或許我們也是如此，也即先有簡(jiǎn)單的層次，生物-植物-ABC，隨后逐步細(xì)化功能迭代開發(fā)。

  • 類與接口

    抽象類與接口十分相像，一般用借口能實(shí)現(xiàn)的東西我們都可以通過抽象類來實(shí)現(xiàn)，但從結(jié)構(gòu)上看來，抽象類是分類，接口是功能，就像圖中的光合作用是接口，樹和草是類，樹和草描述的是實(shí)體的構(gòu)成模式，光合作用描述的是他們所具有的功能，還是有很大區(qū)別的。

  • 抽象類
    抽象類并不是不可以指代一個(gè)對(duì)象，僅僅是不能實(shí)例化一個(gè)對(duì)象，實(shí)例化的對(duì)象可以通過抽象類來指代，就像故宮里的那顆植物可能是一棵樹，但是同樣可以通過植物來指代。

二、實(shí)踐與設(shè)計(jì)思路

　　至今為止面向?qū)ο箝_課以來已歷五周，共實(shí)現(xiàn)了三次作業(yè)，都是表達(dá)式求導(dǎo)，功能逐步增加，對(duì)于面向?qū)ο罄斫獾闹鸩郊由钜矊?duì)我的程序結(jié)構(gòu)產(chǎn)生了不同的影響，以下作出歸納：

　　

• HomeWork1

　　題目描述：多項(xiàng)式求導(dǎo)，多項(xiàng)式僅由帶符號(hào)整數(shù)、x的一次函數(shù)與x的冪函數(shù)構(gòu)成。

　　對(duì)于面向?qū)ο笠恢虢?#xff0c;以為一個(gè)類用于當(dāng)作函數(shù)主路口，另一個(gè)類用于實(shí)現(xiàn)功能就已經(jīng)半只腳踩入面向?qū)ο蟮拇箝T了；實(shí)際上不過是“include”一個(gè)頭文件的過程式設(shè)計(jì)而已。當(dāng)然功能實(shí)現(xiàn)沒有問題，只不過到了HomeWork2需要重寫了。且結(jié)構(gòu)上維護(hù)困難。

　　由于Derivation類僅僅實(shí)現(xiàn)函數(shù)的入口功能，連格式判斷都放在Poltnomia類中，所以直接的結(jié)果就是該類的體量巨大，度量數(shù)據(jù)超標(biāo)都是此類的問題。

　　另一方面，由于正則表達(dá)式判斷時(shí)(getIn方法)使用的是多個(gè)if-else-return結(jié)構(gòu)，結(jié)構(gòu)化程度ev(G)與循環(huán)復(fù)雜度v(G)都很大。但調(diào)試與理解起來并不是很令人費(fèi)解，當(dāng)然這是個(gè)人非數(shù)據(jù)的感覺。

　　總而言之，第一次作業(yè)的實(shí)現(xiàn)并沒有明白面向?qū)ο蟪绦虻木帉懛绞?#xff0c;用完全過程式的思想去編寫程序，唯一覺的有利于編程的是java巨大方便的類庫(kù)～

?

• HomeWork2

　　題目描述：多項(xiàng)式求導(dǎo)，多項(xiàng)式由帶符號(hào)整數(shù)、x的一次函數(shù)、x的冪函數(shù)與x的sin、cos函數(shù)構(gòu)成。

　　題目一出來，就發(fā)現(xiàn)第一次的作業(yè)白寫了，于是有感為了讓第三次的作業(yè)好寫一些，盡力的修修補(bǔ)補(bǔ)得到了如下的結(jié)構(gòu)。因?yàn)閷懙臅r(shí)候并沒有題頭的所述的那般理解清楚，所以很多結(jié)構(gòu)上有冗余，第一次使用繼承、抽象類，還沒有很深的理解，于是勉強(qiáng)有如下的結(jié)構(gòu)，但自認(rèn)為結(jié)構(gòu)上或不甚清晰，類內(nèi)部的實(shí)現(xiàn)有些混亂。主要體現(xiàn)在AddFunction和MultyFunction的組成，使用了Function的Array組成其數(shù)據(jù)結(jié)構(gòu)，但一方面這debug不方便，另一方面優(yōu)化時(shí)不容易。

　　首先從類圖看，Term是函數(shù)入口，Function作為求導(dǎo)函數(shù)的頂層抽象類，直接繼承它的是加和函數(shù)、乘積函數(shù)和基本函數(shù)，基本函數(shù)也是抽象類，其有冪函數(shù)、X函數(shù)、常數(shù)函數(shù)和sin、cos函數(shù)五個(gè)子類。從結(jié)構(gòu)實(shí)現(xiàn)上，基本實(shí)現(xiàn)了我所預(yù)想的結(jié)構(gòu)。但靜態(tài)分析仍有問題。

　　如上圖，由于方法過長(zhǎng)，右邊的方法僅給出了超標(biāo)部分的截圖。

　　從類的結(jié)構(gòu)來看，Term和Function的平均復(fù)雜度很高，這是由于Term沿用了正則表達(dá)式判斷輸入格式的方法，仍然是if-else-return加大了復(fù)雜度，Function是因?yàn)榧婢吡斯S函數(shù)的功能，并不僅僅作為抽象類而存在，我想這應(yīng)該需要避免，功能和數(shù)據(jù)結(jié)構(gòu)的定義最好分開。

　　從方法復(fù)雜度看兩個(gè)match方法都是使用了正則表達(dá)式if-else-return的結(jié)構(gòu)，加大了復(fù)雜度。而Multy中的getout主要原因是用多個(gè)if結(jié)構(gòu)來優(yōu)化造成的結(jié)果。

　　類間的相互依賴關(guān)系如上，因?yàn)镸ultyFunction和AddFunction中的函數(shù)項(xiàng)組成采用了頂層抽象類型，即內(nèi)部類型結(jié)構(gòu)表述與思考有些混亂，為了避免出現(xiàn)錯(cuò)誤，就使用了最大的描述類型。這點(diǎn)在第三次作業(yè)做了些改變。

• ?HomeWork3

　　題目描述：多項(xiàng)式求導(dǎo)，多項(xiàng)式由帶符號(hào)整數(shù)、x的一次函數(shù)、x的冪函數(shù)與x的sin、cos函數(shù)構(gòu)成，允許sin、cos內(nèi)部嵌套表達(dá)式及其他函數(shù)，允許冪函數(shù)底數(shù)使用x的函數(shù)項(xiàng)或表達(dá)式。

　　由于第二次作業(yè)的正確決策，第三次就不需要重新考慮結(jié)構(gòu)，僅僅調(diào)整了冪函數(shù)的位置，并對(duì)結(jié)構(gòu)內(nèi)部進(jìn)行了一些修改與優(yōu)化，包括精確化函數(shù)類型，加和函數(shù)明確為乘積函數(shù)組成，乘積函數(shù)明確為冪函數(shù)組成，考慮嵌套，冪函數(shù)、三角函數(shù)內(nèi)部使用加和函數(shù)類型。正則表達(dá)式判斷格式直接使用了第二次的代碼，基本沒什么修改。另一方面，分離了工廠函數(shù)和頂層抽象類，使得結(jié)構(gòu)更加清晰。

　　類圖結(jié)構(gòu)上并未有太大變化，入口函數(shù)在Derive類。

　　Derive類中包含了match正則表達(dá)式匹配方法，if-else-return結(jié)構(gòu)使復(fù)雜度增大。當(dāng)然，關(guān)于這個(gè)問題，可以通過遞歸分部解決，在遞歸部分我也加入了判斷，或許程序中有冗余，但是并沒有太在意去改變。CreatFunction類是生成函數(shù)，因?yàn)樾枰ㄌ?hào)匹配，這一點(diǎn)或許可以通過遞歸逐層解決，但是在這次作業(yè)中，我使用的是過程式匹配，這或許有違面向?qū)ο蟮某踔浴?/p>

　　由于結(jié)構(gòu)的更改，Power作為優(yōu)化中極為重要的一步，通過if來進(jìn)行判斷。復(fù)雜度略有增加。

　　另一方面，因?yàn)橐婚_始寫的時(shí)候并沒有了解到instanceof可以判斷函數(shù)具體到那個(gè)子類。所以有isBaseOr。。。來判斷嵌套函數(shù)是否是常數(shù)函數(shù)或者表達(dá)式函數(shù)。

　

　　通過清晰化結(jié)構(gòu)一定程度降低了類間的依賴度。

?

• 總結(jié)

　　三次作業(yè)的第一次作業(yè)完全按面向過程式編程，維護(hù)程度比較低下，程序測(cè)試分?jǐn)?shù)也較低。第二次作業(yè)，第一次用了面向?qū)ο蟮乃悸肪帉懗绦?#xff0c;雖然測(cè)試分?jǐn)?shù)更低了。。。當(dāng)然或許第一次作業(yè)沒有為第二次作業(yè)留下出了bug數(shù)據(jù)以為的好處。第三次作業(yè)很大程度上復(fù)用了第二次作業(yè)的代碼，得到了不錯(cuò)的成績(jī)，也算是一種鼓勵(lì)吧～體會(huì)到了復(fù)用的好處。

?

三、bug分析

• 第一、二次作業(yè)

公測(cè)

　　第一次作業(yè)屬于格式輸出錯(cuò)誤，應(yīng)該是正則表達(dá)式不熟練的問題。

　　第二次函數(shù)遞歸結(jié)構(gòu)內(nèi)部出現(xiàn)問題，在三角函數(shù)的輸出時(shí)沒有考慮負(fù)數(shù)的情況。

互測(cè)
　　關(guān)于前兩次互測(cè)，被發(fā)現(xiàn)的bug都是FormatWrong，正則表達(dá)式考慮不完全所造成的后果……因?yàn)橥ㄟ^正則表達(dá)式判別，或許與設(shè)計(jì)結(jié)構(gòu)關(guān)聯(lián)不大，一二次的結(jié)果相似。

hack策略
　　通過自己程序的bug和復(fù)用曾經(jīng)自己被hack的bug來測(cè)試別人的bug。效果不錯(cuò)。也有可能是因?yàn)樯硖嶤組的緣故。
　　查看別人的源代碼，有針對(duì)的hack，成功率很高，但是效率比較低，看別人代碼大多數(shù)時(shí)候真的很累。

• 第三次作業(yè)

公測(cè)
　　優(yōu)化時(shí)多次進(jìn)行括號(hào)匹配，結(jié)果超時(shí)了，這一塊是可以避免的而用其他方法實(shí)現(xiàn)，當(dāng)當(dāng)時(shí)沒有想到。。。

互測(cè)
　　因?yàn)椴粶y(cè)WrongFormat！！！（如果測(cè)可能還是有問題）所以被hack的主要內(nèi)容是關(guān)于常數(shù)項(xiàng)的判斷，與前兩次類似的地方在于，都出現(xiàn)在方法復(fù)雜度高的地方。
　　有一為同學(xué)可能很認(rèn)真的看了我代碼，代碼結(jié)構(gòu)的安排上有瑕疵，輸出會(huì)出現(xiàn)表達(dá)式作為底數(shù)的情況，這點(diǎn)我在寫程序的時(shí)候并為考慮，實(shí)現(xiàn)時(shí)認(rèn)為表達(dá)式可以作為底數(shù)，于是輸出也作為底數(shù)，結(jié)果要求一變就涼了。。。

hack策略
　　通過自己程序的bug和復(fù)用曾經(jīng)自己被hack的bug來測(cè)試別人的bug。
　　查看別人的源代碼，有針對(duì)的hack，未成功過。。。或許是水平不夠。?

四、總結(jié)與Applying Creational Pattern

　　大概收獲最大的并不是某次作業(yè)，而是最后的一次同學(xué)分享。就如題頭說的，面向?qū)ο蟮慕?gòu)不是一蹴而就的，或許我們最先反應(yīng)過來的模型都是簡(jiǎn)單的相對(duì)不抽象也不細(xì)化，得到的體系與結(jié)構(gòu)也僅僅是不完善的。

　　表達(dá)式求導(dǎo)，在第二次采用面向?qū)ο蠓椒ㄔO(shè)計(jì)的時(shí)候，確實(shí)在碼代碼之前進(jìn)行了深入的思考，想清楚得得到一個(gè)清晰的架構(gòu)，最后的結(jié)果是得到了一個(gè)初步的模型，但對(duì)于內(nèi)部細(xì)節(jié)并沒有很完善，具體的分析前文提到了。通過反思與和同學(xué)的交流，在第三次作業(yè)重寫了部分方法，重新整理了數(shù)據(jù)結(jié)構(gòu)，相對(duì)的跟清晰的獲得了體系。當(dāng)然任然存在在不完善的地方，通過反思與思考仍然可以更進(jìn)一步的優(yōu)化～

轉(zhuǎn)載于:https://www.cnblogs.com/YeSiyuan/p/10607982.html

總結(jié)

以上是生活随笔為你收集整理的面向对象第一单元总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。