1汉形、單一職能原則(Single Responsibility Principle, SRP)
定義
There should never be more than one reason for a class to change.
應(yīng)該有且僅有一個原因引起類的變更
換言之咙轩,也就是一個接口或類只有一個職責(zé)
好處
- 類的復(fù)雜性降低,實現(xiàn)什么職責(zé)都有清晰明確的定義又跛;
- 可讀性提高腮恩,復(fù)雜性降低埋嵌,那當(dāng)然可讀性提高了狐援;
- 可維護(hù)性提高,可讀性提高某筐,那當(dāng)然更容易維護(hù)了比搭;
- 變更引起的風(fēng)險降低,變更時必不可少的南誊,如果接口的單一職責(zé)做得好身诺,一個接口修改只對相應(yīng)的實現(xiàn)類有影響,對其他的接口無影響抄囚,這對系統(tǒng)的擴(kuò)展性霉赡、維護(hù)性都有非常大的幫助。
最佳實踐
職責(zé)的劃分很難幔托,要想完全符合單一職責(zé)的設(shè)計更難穴亏,原則是接口一定要做到單一職責(zé),類的設(shè)計盡量做到只有一個原因引起變化
2重挑、里氏替換原則(LiskovSubstitution Principle嗓化,LSP)
繼承的利與弊
- 優(yōu)點
- 代碼共享,減少創(chuàng)建類的工作量谬哀,每個子類都擁有父類的方法和屬性刺覆;
- 提高代碼的重用性;
- 子類可以形似父類史煎,但又異于父類谦屑;
- 提高代碼的可擴(kuò)展性,實現(xiàn)父類的方法就可以“為所欲為”了篇梭;
- 提高產(chǎn)品或項目的開放性氢橙。
- 缺點
- 繼承是侵入性的。只要繼承恬偷,就必須擁有父類的所有屬性和方法悍手;
- 降低代碼的靈活性。子類必須擁有父類的屬性和方法,讓子類自由的世界中多了些約束谓苟;
- 增強(qiáng)了耦合性。當(dāng)父類的常量协怒、變量和方法被修改時涝焙,需要考慮子類的修改,而且在缺乏規(guī)范的環(huán)境下孕暇,這種修改可能帶來非常糟糕的結(jié)果——大段的代碼需要重構(gòu)仑撞。
定義
If for each object o1 of type S there is an object o2 oftype T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 issubstituted for o2 then S is a subtype of T.
如果對每一個類型為S的對象o1,都有類型為T的對象o2妖滔,使得以T定義的所有程序P在所有的對象o1都代換成o2時隧哮,程序P的行為沒有發(fā)生變化,那么類型S是類型T的子類型座舍。
以上是LSP"最正宗"的定義沮翔,但是可能不太容易理解,它還有另外一種相對清晰明確的定義:
Functions that use pointers or references to base classes must be able to useobjects of derived classes without knowing it.
所有引用基類的地方必須能透明地使用其子類的對象曲秉。
通俗點講采蚀,只要父類能出現(xiàn)的地方子類就可以出現(xiàn),而且替換為子類也不會產(chǎn)生任何錯誤或異常承二,使用者可能根本就不需要知道是父類還是子類榆鼠。但是,反過來就不行了亥鸠,有子類出現(xiàn)的地方妆够,父類未必就能適應(yīng)。(LSP可以正著用但不能反著用)
規(guī)范
里氏替換原則為良好的繼承定義了一個規(guī)范负蚊,一句簡單的定義包含了4層含義:
-
子類必須完全實現(xiàn)父類的方法
如果子類不能完整地實現(xiàn)父類的方法神妹,或者父類的某些方法在子類中已經(jīng)發(fā)生“畸變”,則建議斷開父子繼承關(guān)系盖桥,采用依賴灾螃、聚集、組合等關(guān)系代替繼承揩徊。
子類可以有自己的個性
覆蓋或?qū)崿F(xiàn)父類的方法時輸入?yún)?shù)可以被放大(重載而非覆蓋)
-
覆寫或?qū)崿F(xiàn)父類的方法時輸出結(jié)果可以被縮小
父類的一個方法的返回值是一個類型T腰鬼,子類的相同方法(重載或覆寫)的返回值為S,那么里氏替換原則就要求S必須小于等于T塑荒,也就是說熄赡,要么S和T是同一個類型,要么S是T的子類齿税。
最佳實踐
在項目中彼硫,采用里氏替換原則時,盡量避免子類的“個性”,一旦子類有“個性”拧篮,這個子類和父類之間的關(guān)系就很難調(diào)和了词渤,把子類當(dāng)做父類使用,子類的“個性”被抹殺——委屈了點串绩;把子類單獨作為一個業(yè)務(wù)來使用缺虐,則會讓代碼間的耦合關(guān)系變得撲朔迷離——缺乏類替換的標(biāo)準(zhǔn)。
3礁凡、依賴倒置原則(Dependence Inversion Principle,DIP)
定義
High level modules should not depend upon low level modules.Both should depend uponabstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
- 高層模塊不應(yīng)該依賴低層模塊高氮,兩者都應(yīng)該依賴其抽象;
- 抽象不應(yīng)該依賴細(xì)節(jié)顷牌;
- 細(xì)節(jié)應(yīng)該依賴抽象剪芍。
依賴倒置原則在Java中的體現(xiàn):
- 模塊間的依賴通過抽象發(fā)生,實現(xiàn)類之間不發(fā)生直接的依賴關(guān)系窟蓝,其依賴關(guān)系是通過接口或抽象類產(chǎn)生的罪裹;
- 接口或抽象類不依賴于實現(xiàn)類;
- 實現(xiàn)類依賴接口或抽象類疗锐。
更加精簡的定義就是“面向接口編程”坊谁。
依賴的三種寫法
- 構(gòu)造函數(shù)傳遞依賴對象(構(gòu)造函數(shù)注入),在類中通過構(gòu)造函數(shù)聲明依賴對象
- Setter方法傳遞依賴對象(Setter依賴注入)滑臊,在抽象中設(shè)置Setter方法聲明依賴關(guān)系
- 在接口的方法中聲明依賴對象(接口注入)
最佳實踐
依賴倒置原則的本質(zhì)就是通過抽象(接口或抽象類)使各個類或模塊的實現(xiàn)彼此獨立口芍,不互相影響,實現(xiàn)模塊間的松耦合雇卷,我們怎么在項目中使用這個規(guī)則呢鬓椭?只要遵循以下的幾個規(guī)則就可以:
-
每個類盡量都有接口或抽象類,或者抽象類和接口兩者都具備
這是依賴倒置的基本要求关划,接口和抽象類都是屬于抽象的小染,有了抽象才可能依賴倒置
變量的表面類型盡量是接口或者是抽象類
任何類都不應(yīng)該從具體類派生
盡量不要覆寫基類的方法
-
結(jié)合里氏替換原則使用
父類出現(xiàn)的地方子類就能出現(xiàn),再DIP贮折,我們可以得出這樣一個通俗的規(guī)則: 接口負(fù)責(zé)定義public屬性和方法裤翩,并且聲明與其他對象的依賴關(guān)系,抽象類負(fù)責(zé)公共構(gòu)造部分的實現(xiàn)调榄,實現(xiàn)類準(zhǔn)確的實現(xiàn)業(yè)務(wù)邏輯踊赠,同時在適當(dāng)?shù)臅r候?qū)Ω割愡M(jìn)行細(xì)化。
依賴倒置原則是6個設(shè)計原則中最難以實現(xiàn)的原則每庆,它是實現(xiàn)開閉原則的重要途徑筐带,依賴倒置原則沒有實現(xiàn),就別想實現(xiàn)對擴(kuò)展開放缤灵,對修改關(guān)閉伦籍。在項目中蓝晒,大家只要記住是“面向接口編程”就基本上抓住了依賴倒置原則的核心。
4帖鸦、接口隔離原則(Interface Segregations Principle, ISP)
定義
接口隔離原則有以下兩種定義:
Clients should not be forced to depend upon interfaces that they don't use.
客戶端不應(yīng)該依賴它不需要的接口芝薇。
解釋:客戶端需要什么接口就提供什么接口,把不需要的接口剔除掉作儿,那就需要對接口進(jìn)行細(xì)化剩燥,保證其純潔性;
The dependency of one class to another one should depend on the smallest possible interface.
類間的依賴關(guān)系應(yīng)該建立在最小的接口上立倍。
解釋:要求是最小的接口,也是要求接口細(xì)化侣滩,接口純潔口注,與第一個定義如出一轍,只是一個事物的兩種不同描述君珠。
概括:建立單一接口寝志,不要建立臃腫龐大的接口。再通俗一點講:接口盡量細(xì)化策添,同時接口中的方法盡量少材部。
接口隔離原則 VS 單一職責(zé)原則
接口隔離原則與單一職責(zé)的審視角度是不相同的
單一職責(zé)要求的是類和接口職責(zé)單一,注重的是職責(zé)唯竹,這是業(yè)務(wù)邏輯上的劃分乐导;
接口隔離原則要求接口的方法盡量少。
例如一個接口的職責(zé)可能包含10個方法浸颓,這10個方法都放在一個接口中物臂,并且提供給多個模塊訪問,各個模塊按照規(guī)定的權(quán)限來訪問产上,在系統(tǒng)外通過文檔約束“不使用的方法不要訪問”棵磷,按照單一職責(zé)原則是允許的,按照接口隔離原則是不允許的晋涣,因為它要求“盡量使用多個專門的接口”仪媒。專門的接口指什么?就是指提供給每個模塊的都應(yīng)該是單一接口谢鹊,提供給幾個模塊就應(yīng)該有幾個接口算吩,而不是建立一個龐大的臃腫的接口,容納所有的客戶端訪問撇贺。
// TODO 還是感覺差不太多...
規(guī)范
-
接口要盡量小
- 要有限度
- 不能違背單一職責(zé)原則(業(yè)務(wù)上的劃分)
-
接口要高內(nèi)聚
高內(nèi)聚具體到接口隔離原則就是赌莺,要求在接口中盡量少公布public方法,接口是對外的承諾松嘶,承諾越少對系統(tǒng)的開發(fā)越有利艘狭,變更的風(fēng)險也就越少,同時也有利于降低成本。
-
定制服務(wù)(只提供訪問者需要的方法)
舉例說明:一個用于查詢用戶的接口巢音,應(yīng)該提供具體的根據(jù)用戶ID查詢或者根據(jù)用戶名查詢等于業(yè)務(wù)相關(guān)的特定接口遵倦,而不是提供一個帶有Map(或者說類似Mybatis Example)參數(shù)的查詢接口
-
接口設(shè)計是有限度的
- 接口的設(shè)計粒度越小,系統(tǒng)越靈活官撼;
- 但是梧躺,靈活的同時也帶來了結(jié)構(gòu)的復(fù)雜化,開發(fā)難度增加傲绣,可維護(hù)性降低掠哥,這不是一個項目或產(chǎn)品所期望看到的;
- 所以接口設(shè)計一定要注意適度秃诵,這個“度”如何來判斷呢续搀?根據(jù)經(jīng)驗和常識判斷,沒有一個固化或可測量的標(biāo)準(zhǔn)菠净。
最佳實踐
接口隔離原則是對接口的定義禁舷,同時也是對類的定義,接口和類盡量使用原子接口或原子類來組裝毅往。但是牵咙,這個原子該怎么劃分是設(shè)計模式中的一大難題,在實踐中可以根據(jù)以下幾個規(guī)則來衡量:
- 一個接口只服務(wù)于一個子模塊或業(yè)務(wù)邏輯攀唯;
- 通過業(yè)務(wù)邏輯壓縮接口中的public方法洁桌,接口時常去回顧,盡量讓接口達(dá)到“滿身筋骨肉”侯嘀,而不是“肥嘟嘟”的一大堆方法战坤;
- 已經(jīng)被污染了的接口,盡量去修改残拐,若變更的風(fēng)險較大途茫,則采用適配器模式進(jìn)行轉(zhuǎn)化處理;
- 了解環(huán)境溪食,拒絕盲從囊卜。每個項目或產(chǎn)品都有特定的環(huán)境因素,環(huán)境不同错沃,接口拆分的標(biāo)準(zhǔn)就不同栅组。深入了解業(yè)務(wù)邏輯,結(jié)合實際情況進(jìn)行接口設(shè)計枢析。
5玉掸、迪米特法則(Law of Demeter,LoD)
也稱為最少知識原則(Least KnowledgePrinciple醒叁,LKP)
定義
一個對象應(yīng)該對其他對象有最少的了解
通俗地講司浪,一個類應(yīng)該對自己需要耦合或調(diào)用的類知道得最少泊业,你(被耦合或調(diào)用的類)的內(nèi)部是如何復(fù)雜都和我沒關(guān)系,那是你的事情啊易,我就知道你提供的這么多public方法吁伺,我就調(diào)用這么多,其他的我一概不關(guān)心租谈。
含義
-
只和朋友交流
迪米特法則還有一個英文解釋是:
Only talk to your immediate friends.
只與直接的朋友通信篮奄。
一個類只和朋友交流,不與陌生類交流割去,不要出現(xiàn)getA().getB().getC().getD()這種情況(在一種極端的情況下允許出現(xiàn)這種訪問窟却,即每一個點號后面的返回類型都相同),類與類之間的關(guān)系是建立在類間的呻逆,而不是方法間间校,因此一個方法盡量不引入一個類中不存在的對象,當(dāng)然页慷,JDK API提供的類除外。
-
朋友間也是有距離的
迪米特法則要求類“羞澀”一點胁附,盡量不要對外公布太多的public方法和非靜態(tài)的public變量酒繁,盡量內(nèi)斂,多使用private控妻、package-private州袒、protected等訪問權(quán)限。
-
是自己的就是自己的
在實際應(yīng)用中經(jīng)常會出現(xiàn)這樣一個方法:放在本類中也可以弓候,放在其他類中也沒有錯郎哭,那怎么去衡量呢?你可以堅持這樣一個原則:如果一個方法放在本類中菇存,既不增加類間關(guān)系夸研,也對本類不產(chǎn)生負(fù)面影響,那就放置在本類中依鸥。
謹(jǐn)慎使用Serializable
最佳實踐
迪米特法則的核心觀念就是類間解耦亥至,弱耦合,只有弱耦合了以后贱迟,類的復(fù)用率才可以提高姐扮。其要求的結(jié)果就是產(chǎn)生了大量的中轉(zhuǎn)或跳轉(zhuǎn)類,導(dǎo)致系統(tǒng)的復(fù)雜性提高衣吠,同時也為維護(hù)帶來了難度茶敏。在采用迪米特法則時需要反復(fù)權(quán)衡,既做到讓結(jié)構(gòu)清晰缚俏,又做到高內(nèi)聚低耦合惊搏。
迪米特法則要求類間解耦贮乳,但解耦是有限度的,除非是計算機(jī)的最小單元——二進(jìn)制的0和1胀屿。那才是完全解耦塘揣,在實際的項目中,需要適度地考慮這個原則宿崭,別為了套用原則而做項目亲铡。原則只是供參考,如果違背了這個原則葡兑,項目也未必會失敗奖蔓,這就需要大家在采用原則時反復(fù)度量,不遵循是不對的讹堤,嚴(yán)格執(zhí)行就是“過猶不及”吆鹤。
6、開閉原則(Open Closed Principle, OCP)
開閉原則是Java世界里最基礎(chǔ)的設(shè)計原則洲守,它指導(dǎo)我們?nèi)绾谓⒁粋€穩(wěn)定的疑务、靈活的系統(tǒng)
定義
Software entities like classes,modules and functions should be open for extension but closed formodifications.
一個軟件實體如類、模塊和函數(shù)應(yīng)該對擴(kuò)展開放梗醇,對修改關(guān)閉知允。
換句話說,一個軟件實體應(yīng)該通過擴(kuò)展來實現(xiàn)變化叙谨,而不是通過修改已有的代碼來實現(xiàn)變化温鸽。
重要性
開閉原則是最基礎(chǔ)的一個原則,前面節(jié)介紹的五個原則都是開閉原則的具體形態(tài)手负,也就是說前五個原則就是指導(dǎo)設(shè)計的工具和方法涤垫,而開閉原則才是其精神領(lǐng)袖。換一個角度來理解竟终,依照J(rèn)ava語言的稱謂蝠猬,開閉原則是抽象類,其他五大原則是具體的實現(xiàn)類统捶,開閉原則在面向?qū)ο笤O(shè)計領(lǐng)域中的地位就類似于牛頓第一定律在力學(xué)吱雏、勾股定律在幾何學(xué)、質(zhì)能方程在狹義相對論中的地位瘾境,其地位無人能及歧杏。
如何使用開閉原則
-
抽象約束
- 通過接口或抽象類約束擴(kuò)展,對擴(kuò)展進(jìn)行邊界限定迷守,不允許出現(xiàn)在接口或抽象類中不存在的public方法犬绒;
- 參數(shù)類型、引用對象盡量使用接口或者抽象類兑凿,而不是實現(xiàn)類凯力;
- 抽象層盡量保持穩(wěn)定茵瘾,一旦確定即不允許修改。
-
元數(shù)據(jù)(metadata)控制模塊行為
何謂元數(shù)據(jù)咐鹤?就是用來描述環(huán)境和數(shù)據(jù)的數(shù)據(jù)拗秘,通俗地說就是配置參數(shù),參數(shù)可以從文件中獲得祈惶,也可以從數(shù)據(jù)庫中獲得雕旨。
制定項目章程(團(tuán)隊約定)
-
封裝變化
- 將相同的變化封裝到一個接口或抽象類中;
- 將不同的變化封裝到不同的接口或抽象類中捧请,不應(yīng)該有兩個不同的變化出現(xiàn)在同一個接口或抽象類中凡涩。
- 封裝變化,也就是受保護(hù)的變化(protected variations)疹蛉,找出預(yù)計有變化或不穩(wěn)定的點活箕,我們?yōu)檫@些變化點創(chuàng)建穩(wěn)定的接口,準(zhǔn)確地講是封裝可能發(fā)生的變化可款,一旦預(yù)測到或“第六感”發(fā)覺有變化育韩,就可以進(jìn)行封裝,23個設(shè)計模式都是從各個不同的角度對變化進(jìn)行封裝的
最佳實踐
-
開閉原則也只是一個原則
開閉原則只是精神口號闺鲸,實現(xiàn)擁抱變化的方法非常多筋讨,并不局限于這6大設(shè)計原則,但是遵循這6大設(shè)計原則基本上可以應(yīng)對大多數(shù)變化翠拣。因此,我們在項目中應(yīng)盡量采用這6大原則游盲,適當(dāng)時候可以進(jìn)行擴(kuò)充误墓,例如通過類文件替換的方式完全可以解決系統(tǒng)中的一些缺陷。大家在開發(fā)中比較常用的修復(fù)缺陷的方法就是類替換益缎,比如一個軟件產(chǎn)品已經(jīng)在運行中谜慌,發(fā)現(xiàn)了一個缺陷,需要修正怎么辦莺奔?如果有自動更新功能欣范,則可以下載一個.class文件直接覆蓋原有的class,重新啟動應(yīng)用(也不一定非要重新啟動)就可以解決問題令哟,也就是通過類文件的替換方式修正了一個缺陷恼琼,當(dāng)然這種方式也可以應(yīng)用到項目中,正在運行中的項目發(fā)現(xiàn)需要增加一個新功能屏富,通過修改原有實現(xiàn)類的方式就可以解決這個問題晴竞,前提條件是:類必須做到高內(nèi)聚、低耦合狠半,否則類文件的替換會引起不可預(yù)料的故障噩死。
-
項目規(guī)章非常重要
如果你是一位項目經(jīng)理或架構(gòu)師颤难,應(yīng)盡量讓自己的項目成員穩(wěn)定,穩(wěn)定后才能建立高效的團(tuán)隊文化已维,章程是一個團(tuán)隊所有成員共同的知識結(jié)晶行嗤,也是所有成員必須遵守的約定。優(yōu)秀的章程能帶給項目帶來非常多的好處垛耳,如提高開發(fā)效率栅屏、降低缺陷率、提高團(tuán)隊士氣艾扮、提高技術(shù)成員水平既琴,等等。
-
預(yù)知變化
在實踐中過程中泡嘴,架構(gòu)師或項目經(jīng)理一旦發(fā)現(xiàn)有發(fā)生變化的可能甫恩,或者變化曾經(jīng)發(fā)生過,則需要考慮現(xiàn)有的架構(gòu)是否可以輕松地實現(xiàn)這一變化酌予。架構(gòu)師設(shè)計一套系統(tǒng)不僅要符合現(xiàn)有的需求磺箕,還要適應(yīng)可能發(fā)生的變化,這才是一個優(yōu)良的架構(gòu)抛虫。
開閉原則是一個終極目標(biāo)松靡,任何人包括大師級人物都無法百分之百做到,但朝這個方向努力建椰,可以非常顯著地改善一個系統(tǒng)的架構(gòu)雕欺,真正做到“擁抱變化”。
7棉姐、總結(jié)
首先屠列,無論是6大設(shè)計原則還是23種設(shè)計模式,根本目標(biāo)其實就是一個"擁抱變化"伞矩,包括需求的變化笛洛、運行環(huán)境的變化、性能要求的提升等等乃坤,實現(xiàn)一個需求并不難苛让,但是當(dāng)變化來臨時,能否泰然處之湿诊,那就是個技術(shù)活了狱杰。
其次,"擁抱變化"落實到代碼層面是什么厅须?——你的代碼是可維護(hù)的浦旱、可擴(kuò)展的,還是說"牽一發(fā)動全身"九杂,一點小的改動很多東西都要跟著變動颁湖。
再次宣蠕,要做到"擁抱變化",讓你的代碼很容易維護(hù)和擴(kuò)展甥捺,核心理念就是"高內(nèi)聚抢蚀、低耦合",以及"面向接口編程(面向抽象編程)”
最后镰禾,設(shè)計原則皿曲、設(shè)計模式是前輩總結(jié)的"經(jīng)驗",但不是"條款"吴侦,盡可能遵循這些規(guī)范會讓你的設(shè)計無限接近完美屋休,但世界上本就沒有十全十美的東西,凡事都要有個度备韧,不要認(rèn)死理劫樟,不要為了"套模式"而應(yīng)用設(shè)計模式,要具體問題具體分析织堂,根據(jù)實際情況進(jìn)行權(quán)衡叠艳。
設(shè)計做得再漂亮,代碼寫得再完美易阳,項目做得再符合標(biāo)準(zhǔn)附较,一旦項目虧本,產(chǎn)品投入大于產(chǎn)出潦俺,那整體就是扯淡拒课!
參考文獻(xiàn):《設(shè)計模式之禪》