1、單一職責(zé)
代碼優(yōu)化第一步,單一職責(zé)原則 (Single Responsibility Principle)。對(duì)于一個(gè)Java類,應(yīng)該僅有一個(gè)引起它變化的原因,也就是說(shuō),一個(gè)類中,應(yīng)該是一組相關(guān)性很高的函數(shù)、數(shù)據(jù)的封裝。但是這個(gè)原則的界限劃分的并不是那么清晰,很大程度上要依賴于開(kāi)發(fā)者的個(gè)人經(jīng)驗(yàn)來(lái)定。對(duì)于單一職責(zé)界限的劃分最大的問(wèn)題就是類的職責(zé)是什么,如何劃分類的職責(zé)。
單一職責(zé)原則在我們實(shí)際工作中隨處可見(jiàn),例如在我們比較關(guān)心的框架MVC,MVP中,負(fù)責(zé)頁(yè)面展示的Activity,F(xiàn)ragment,以及各種View,它們只負(fù)責(zé)UI的展示,具體的業(yè)務(wù)邏輯則交付給Controller或者Presenter.。再例如各種流行的圖片加載框架,在其中都可以找到專門(mén)負(fù)責(zé)圖片加載類,圖片緩存的類。所以,單一職責(zé)原則是我們代碼優(yōu)化的第一步,也是最重要的一步。
2、開(kāi)閉原則
開(kāi)閉原則(Open Close Principle),是Java世界里最基礎(chǔ)的設(shè)計(jì)原則,它指導(dǎo)我們?nèi)绾谓⒁粋€(gè)穩(wěn)定、靈活的系統(tǒng)。開(kāi)閉原則定義:軟件中的對(duì)象(類,模塊、函數(shù)等)應(yīng)該對(duì)于擴(kuò)展是開(kāi)放的,對(duì)于修改的封閉的。在軟件的生命周期內(nèi),因?yàn)樽兓?、升?jí)、維護(hù)等原因需要對(duì)軟件原有的代碼進(jìn)行修改時(shí),可能會(huì)將錯(cuò)誤引入原本已經(jīng)測(cè)試過(guò)的舊代碼,破壞原有系統(tǒng),因此,當(dāng)軟件需要變化時(shí),我們應(yīng)該進(jìn)肯能通過(guò)擴(kuò)展的方式來(lái)實(shí)現(xiàn)變化,而不是通過(guò)修改已有的代碼來(lái)實(shí)現(xiàn)。但這也不是絕對(duì)的,在實(shí)際開(kāi)發(fā)過(guò)程中,只通過(guò)繼承的方式來(lái)升級(jí)、維護(hù)原有系統(tǒng)是一個(gè)理想化的情況,因此,實(shí)際開(kāi)發(fā)中,修改原有代碼、擴(kuò)展代碼往往是同時(shí)存在的。而如何確保原有軟件模塊的正確性,以及盡量少地影響原有代碼模塊,答案就是盡量遵守開(kāi)閉原則。
3、里氏替換原則
里氏替換原則(Liskov Substitution Principle),定義:如果對(duì)于每一個(gè)類型為ClassA的對(duì)象a,都有類型為ClassB的對(duì)象b,使得以ClassB定義的所有程序P在所有的對(duì)象b都替換成a時(shí),程序P的行為沒(méi)有發(fā)生變化,那么類型ClassA是類型ClassB的子類型。然而這段敘述并無(wú)卵用,更直接的定義是:所有引用基類的地方必須能透明的使用其子類的對(duì)象。
我們知道,面向?qū)ο蟮娜筇攸c(diǎn)是:繼承,封裝,多態(tài),里氏替換原則就是依賴于繼承、多態(tài)這兩大特性。里氏替換原則簡(jiǎn)單來(lái)說(shuō)就是,所有引用基類的地方,必須能使用子類對(duì)象。也就是說(shuō)只要父類能出現(xiàn)的地方,其子類就可以出現(xiàn)。而且替換為子類不會(huì)產(chǎn)生任何錯(cuò)誤和差異。使用者可能根部就不需要知道是父類還是子類,但是反過(guò)來(lái)就行不了,有子類出現(xiàn)的地方父類未必就能適應(yīng)。其實(shí)歸根結(jié)底,里氏替換原則就是基于這兩個(gè)字:抽象
例如在Android中,頁(yè)面Window的展示依賴于View,而View定義了一個(gè)視圖抽象,measure以及draw是其子類共享的方法,子類通過(guò)復(fù)寫(xiě)measure以及draw方法,可實(shí)現(xiàn)各式各樣功能以及視圖的view,任何繼承自View的子類都可以傳遞給Window,由Window負(fù)責(zé)組織View,并將View顯示到屏幕上,這就是所說(shuō)的里氏替換原則。
里氏替換原則的核心原理是抽象,抽象又依賴于繼承,在OOP當(dāng)中,繼承的優(yōu)缺點(diǎn)都相當(dāng)明顯。
繼承的優(yōu)點(diǎn):
代碼重用,減少創(chuàng)建類的成本,每個(gè)子類都擁有父類的方法和屬性
子類和父類基本相似,但又與父類有所區(qū)別
提高代碼的可擴(kuò)展性
繼承的缺點(diǎn):
繼承是入侵性的,只要繼承就必須擁有父類的所有屬性和方法
可能造成子類代碼冗余,靈活性降低,因?yàn)樽宇惐仨殦碛懈割惖姆椒ê蛯傩?/p>
但事物總有兩面性,符合權(quán)衡和利用都是需要根據(jù)具體情況來(lái)做出選擇。在開(kāi)發(fā)過(guò)程中運(yùn)用抽象是走向代碼優(yōu)化的重要一步。
4、依賴倒置原則
依賴倒置原則(Dependence Inversion Principle),依賴倒置原則指定了一種特定的解耦形式,使得高層次的模塊不依賴于低層次的模塊的實(shí)現(xiàn)細(xì)節(jié)的目的,依賴模塊被顛倒了。然而定義往往的不好理解的,依賴倒置原則有以下幾個(gè)關(guān)鍵點(diǎn):
高層模塊不應(yīng)該依賴低層模塊,兩者都應(yīng)該依賴其抽象
抽象不應(yīng)該依賴細(xì)節(jié)
細(xì)節(jié)應(yīng)該依賴抽象
在Java 語(yǔ)言中,抽象就是指接口或抽象類,兩者都是不能直接被實(shí)例化的。細(xì)節(jié)就是實(shí)現(xiàn)類,實(shí)現(xiàn)接口或繼承抽象類而產(chǎn)生的類就是細(xì)節(jié),其特點(diǎn)是,可以直接被實(shí)例化。高層模塊就是調(diào)用端,低層模塊就是具體實(shí)現(xiàn)類。依賴倒置原則在Java語(yǔ)言中的表現(xiàn)就是:模塊間的依賴通過(guò)抽象發(fā)生,實(shí)現(xiàn)類之間不發(fā)生直接的依賴關(guān)系,其依賴關(guān)系是通過(guò)接口或?qū)崿F(xiàn)類產(chǎn)生的。其實(shí)一句話就是:面向接口,或者面向抽象編程。 如果類于類直接依賴于細(xì)節(jié),那么它們之間就有直接耦合,當(dāng)具體實(shí)現(xiàn)需要變化時(shí),意味著要同時(shí)修改依賴者的代碼,這限制了系統(tǒng)的可擴(kuò)展性。
5、接口隔離原則
接口隔離原則(Interface Segregation Principle),它的定義是:客戶端不應(yīng)該依賴它不需要的接口。另一種定義是:類間的依賴關(guān)系應(yīng)該建立在最小的接口上。接口隔離原則將非常龐大,臃腫的接口拆分成更小的接口和更具體的接口,這樣客戶只需要知道他們感興趣的方法。接口隔離原則的目的是系統(tǒng)解開(kāi)耦合,從而容易重構(gòu)、更改和重新部署。
定義總是不好理解的,我們通過(guò)一段代碼來(lái)理解一下接口隔離原則的具體使用。比如我們常見(jiàn)的輸出流OutputStream,使用之后需要將其關(guān)閉:
我們看到,這段代碼的可讀性非常差,各種try catch嵌套的都是極其簡(jiǎn)單的代碼,那么我們?nèi)绾谓鉀Q這個(gè)問(wèn)題呢?在Java中有一個(gè)Closeable接口:
該接口標(biāo)識(shí)了一個(gè)可關(guān)閉的對(duì)象,它只有一個(gè)close方法,而我們的FileOutputStream也實(shí)現(xiàn)了這個(gè)接口。這樣我們就好辦了,我們可以依賴Closeable 接口實(shí)現(xiàn)一個(gè)工具類:
在實(shí)際的運(yùn)用中,我們只需要這樣:
代碼簡(jiǎn)潔了很多,而且這個(gè)工具類可以運(yùn)用到各類可關(guān)閉的對(duì)象中,保證了代碼的重用性。CloseUtils的closeQuietly方法的基本原理就是依賴于CLoseable抽象而不是具體實(shí)現(xiàn),并且建立在最小化依賴原則的基礎(chǔ)上,它只需要知道這個(gè)對(duì)象是可關(guān)閉的,其他的一概不關(guān)心,也就是我們所提出的接口隔離原則。
6、迪米特原則
迪米特原則(Law of Demeter),也成為最少知識(shí)原則:一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象有最少的了解。也就是說(shuō),一個(gè)類應(yīng)該對(duì)自己需要耦合或者調(diào)用的類知道的最少,類的內(nèi)部如何實(shí)現(xiàn)與調(diào)用者或者依賴者沒(méi)關(guān)系,調(diào)用者和依賴者只需要知道它需要的方法即可,其他的一概不管。類與類的關(guān)系越密切,耦合度越大,當(dāng)一個(gè)類發(fā)生改變時(shí),對(duì)另一個(gè)類的影響也越大。
就比如說(shuō)MVP框架中的Model層的實(shí)現(xiàn),我們都知道Model抽象是給View提供具體的數(shù)據(jù),而我們的View層并不需要知道數(shù)據(jù)是怎么得來(lái)的,就算我們后臺(tái)接口如何改變,只要數(shù)據(jù)結(jié)構(gòu)不變,那我們就不需要通知View層進(jìn)行改變。
-
JAVA
+關(guān)注
關(guān)注
19文章
2943瀏覽量
104100 -
代碼
+關(guān)注
關(guān)注
30文章
4671瀏覽量
67766
原文標(biāo)題:Java代碼優(yōu)化六大原則
文章出處:【微信號(hào):Imgtec,微信公眾號(hào):Imagination Tech】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論