“面向?qū)ο蟆睂Ρ取昂瘮?shù)”編程的優(yōu)勢在哪里?
當(dāng)前位置:點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
又看到網(wǎng)上有人聊這個(gè)話題,不禁手癢,也分享下自己的看法。 一、相同點(diǎn)看過不少人說,面向?qū)ο蟮膬?yōu)勢在于它可以基于對象實(shí)現(xiàn)對復(fù)雜系統(tǒng)的分解,以及模塊的復(fù)用,從而降低開發(fā)的難度,提升開發(fā)的效率。 可是基于“函數(shù)”的開發(fā)又何嘗不是如此呢? 函數(shù)一樣可以基于函數(shù)拆解大型的復(fù)雜系統(tǒng)進(jìn)行開發(fā),以及實(shí)現(xiàn)邏輯的復(fù)用,也是一樣會(huì)降低開發(fā)難度,提升開發(fā)效率。 所以,同樣是分解大型復(fù)雜系統(tǒng),基于“對象”的分解和基于“函數(shù)”的分解有何不同呢?前者又比后者“先進(jìn)”在哪里呢? 二、優(yōu)勢在筆者看來,“對象”對比“函數(shù)”的優(yōu)勢主要體現(xiàn)在兩個(gè)方面。 一個(gè)是對象的分解除了邏輯之外,還是包含“狀態(tài)”的,而函數(shù)則是“純邏輯”分解。 另一方面則是,對于“對象”的維護(hù)升級可以基于“開閉原則”進(jìn)行,而函數(shù)無法做到。 三、狀態(tài)拆分對象比函數(shù)多拆分了一個(gè)“狀態(tài)”又有什么好處呢? 因?yàn)橐粋€(gè)系統(tǒng)不可能只是由純粹的邏輯構(gòu)成,它一定還是包含著很多狀態(tài)的。 傳統(tǒng)的函數(shù)只是單純的接收輸入然后返回輸出,之后全部的局部變量都會(huì)被回收,本質(zhì)就是沒有狀態(tài)。 函數(shù)沒有狀態(tài),于是就只能依靠全局變量來管理狀態(tài)。 然后我們就會(huì)發(fā)現(xiàn),系統(tǒng)在邏輯上雖然基于函數(shù)被分解了,但又因?yàn)椤盃顟B(tài)”全部被掛載在“全局變量”上而又“纏繞耦合”在一起。 而“對象”則解決了上述問題,其將原本堆在一起的用以保存狀態(tài)的全局變量,全部以“屬性”的形式分解封裝在各個(gè)相關(guān)的對象之中。 這就實(shí)現(xiàn)了對系統(tǒng)的真正的徹底的分解,不光分解了邏輯,還分解了狀態(tài),不再有“藕斷絲連”。 四、開閉原則面向?qū)ο笾С珠_閉原則意味著其可以在不修改舊代碼的情況下,實(shí)現(xiàn)對舊代碼的升級。 具體來說就是使用“繼承”的方式,讓新類擴(kuò)展舊類,能用的方法直接復(fù)用,想要改的基于“多態(tài)”重寫,而要新增的功能則直接添加。 新類雖然繼承舊類,但其邏輯卻完全不會(huì)對舊類產(chǎn)生影響,從而實(shí)現(xiàn)系統(tǒng)的穩(wěn)健迭代。 也許有人覺得函數(shù)也差不多吧,想要迭代一個(gè)舊函數(shù),怕影響舊代碼完全可以復(fù)制粘貼一個(gè)副本出來進(jìn)行編輯吧? 這里的不同在于,基于“繼承”的擴(kuò)展相比基于“函數(shù)副本”的擴(kuò)展心智負(fù)擔(dān)要低得多。 面向?qū)ο蠡凇袄^承”機(jī)制的開發(fā)本質(zhì)是一種“面向接口”開發(fā)。 在面向接口的開發(fā)中,程序員不必關(guān)心舊類的功能具體是如何實(shí)現(xiàn)的,他只用關(guān)心那些方法具體叫什么名字,實(shí)現(xiàn)了什么功能即可。 而基于一個(gè)函數(shù)副本的二次開發(fā),則要求程序員起碼要搞清楚舊的功能是如何實(shí)現(xiàn)的,需要進(jìn)入到實(shí)現(xiàn)細(xì)節(jié)中,否則根本沒法下手。 這就導(dǎo)致基于函數(shù)的代碼迭代相比基于對象的迭代,在開發(fā)的心智負(fù)擔(dān)方面有了大大增加。 該文章在 2025/10/9 11:05:59 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |