整理總結(jié)自《設(shè)計(jì)模式之禪》一書

1 單一職責(zé)原則

Single Responsibility Principle

是用來規(guī)范一個(gè)類或者接口的職責(zé)應(yīng)該單一，專注。

定義是： 應(yīng)該有且僅有一個(gè)原因引起類的變更。

單一職責(zé)原則有什么好處：

類的復(fù)雜性降低， 實(shí)現(xiàn)什么職責(zé)都有清晰明確的定義赶舆；

可讀性提高倡蝙， 復(fù)雜性降低， 那當(dāng)然可讀性提高了烤低；

可維護(hù)性提高， 可讀性提高魄懂， 那當(dāng)然更容易維護(hù)了咳短；

變更引起的風(fēng)險(xiǎn)降低， 變更是必不可少的嘹悼， 如果接口的單一職責(zé)做得好萌腿， 一個(gè)接口修改只對相應(yīng)的實(shí)現(xiàn)類有影響， 對其他的接口無影響， 這對系統(tǒng)的擴(kuò)展性勘天、 維護(hù)性都有非常大的幫助伏伐。

實(shí)際意義：

應(yīng)該把用戶的信息抽取成一個(gè)BO（Business Object实幕， 業(yè)務(wù)對象） ， 把行為抽取成一個(gè)Biz（Business Logic， 業(yè)務(wù)邏輯） ，單一職責(zé)原則提出了一個(gè)編寫程序的標(biāo)準(zhǔn)府蛇， 用“職責(zé)”或“變化原因”來衡量接口或類設(shè)計(jì)得是否優(yōu)良穷遂， 但是“職責(zé)”和“變化原因”都是不可度量的浦箱， 因項(xiàng)目而異， 因環(huán)境而異對于單一職責(zé)原則妆棒， 我的建議是接口一定要做到單一職責(zé)红选， 類的設(shè)計(jì)盡量做到只有一個(gè)原因引起變化

2 里氏替換原則

Liskov Substitution Principle

用來強(qiáng)調(diào)子類和父類的關(guān)系的坟乾。

定義1：

如果對每一個(gè)類型為S的對象o1殷费， 都有類型為T的對象o2， 使得以T定義的所有程序P在所有的對象o1都代換成o2時(shí)， 程序P的行為沒有發(fā)生變化， 那么類型S是類型T的子類型登钥。

定義2：

所有引用基類的地方必須能透明地使用其子類的對象塔鳍。

通俗點(diǎn)講， 只要父類能出現(xiàn)的地方子類就可以出現(xiàn)， 而且替換為子類也不會(huì)產(chǎn)生任何錯(cuò)誤或異常， 使用者可能根本就不需要知道是父類還是子類。 但是却舀， 反過來就不行了， 有子類出現(xiàn)的地方， 父類未必就能適應(yīng)注意 如果子類不能完整地實(shí)現(xiàn)父類的方法倘是， 或者父類的某些方法在子類中已經(jīng)發(fā)生“畸變”瘤睹， 則建議斷開父子繼承關(guān)系瘪撇， 采用依賴、 聚集度帮、 組合等關(guān)系代替繼承。

子類在沒有覆寫父類的方法的前提下练俐， 子類方法被執(zhí)行了， 這會(huì)引起業(yè)務(wù)邏輯混亂， 因?yàn)樵趯?shí)際應(yīng)用中父類一般都是抽象類， 子類是實(shí)現(xiàn)類蔼紧， 你傳遞一個(gè)這樣的實(shí)現(xiàn)類就會(huì)“歪曲”了父類的意圖哩至， 引起一堆意想不到的業(yè)務(wù)邏輯混亂重荠， 所以子類中方法的前置條件必須與超類中被覆寫的方法的前置條件相同或者更寬松。

實(shí)際意義：

父類的一個(gè)方法的返回值是一個(gè)類型T， 子類的相同方法（重載或覆寫） 的返回值為S， 那么里氏替換原則就要求S必須小于等于T， 也就是說导饲， 要么S和T是同一個(gè)類型袋毙， 要么S是T的子類采用里氏替換原則的目的就是增強(qiáng)程序的健壯性， 版本升級(jí)時(shí)也可以保持非常好的兼容性。 即使增加子類， 原有的子類還可以繼續(xù)運(yùn)行。 在實(shí)際項(xiàng)目中， 每個(gè)子類對應(yīng)不同的業(yè)務(wù)含義， 使用父類作為參數(shù)江耀， 傳遞不同的子類完成不同的業(yè)務(wù)邏輯舌稀， 非常完美缤至！

3 依賴倒置原則

Dependence Inversion Principle

規(guī)范的是類的模塊設(shè)計(jì)月洛，如何設(shè)計(jì)類與類之間的關(guān)系

定義：

依賴倒置原則（Dependence Inversion Principle,DIP） 這個(gè)名字看著有點(diǎn)別扭， “依賴”還“倒置”， 這到底是什么意思？ 依賴倒置原則的原始定義是：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)該依賴抽象。高層模塊和低層模塊容易理解， 每一個(gè)邏輯的實(shí)現(xiàn)都是由原子邏輯組成的， 不可分割的原子邏輯就是低層模塊蒂阱， 原子邏輯的再組裝就是高層模塊。 那什么是抽象？ 什么又是細(xì)節(jié)呢？ 在Java語言中， 抽象就是指接口或抽象類， 兩者都是不能直接被實(shí)例化的；

細(xì)節(jié)就是實(shí)現(xiàn)類， 實(shí)現(xiàn)接口或繼承抽象類而產(chǎn)生的類就是細(xì)節(jié)， 其特點(diǎn)就是可以直接被實(shí)例化， 也就是可以加上一個(gè)關(guān)鍵字new產(chǎn)生一個(gè)對象。

依賴倒置原則在Java語言中的表現(xiàn)就是：

模塊間的依賴通過抽象發(fā)生， 實(shí)現(xiàn)類之間不發(fā)生直接的依賴關(guān)系， 其依賴關(guān)系是通過接口或抽象類產(chǎn)生的俏蛮；

接口或抽象類不依賴于實(shí)現(xiàn)類露该；

實(shí)現(xiàn)類依賴接口或抽象類撵摆。

更加精簡的定義就是“面向接口編程”——OOD（Object-Oriented Design鲫剿， 面向?qū)ο笤O(shè)計(jì)） 的精髓之一殴俱。在Java中李丰， 只要定義變量就必然要有類型， 一個(gè)變量可以有兩種類型： 表面類型和實(shí)際類型， 表面類型是在定義的時(shí)候賦予的類型， 實(shí)際類型是對象的類型， 如zhangSan的表面類型是IDriver， 實(shí)際類型是Driver。依賴是可以傳遞的， A對象依賴B對象， B又依賴C， C又依賴D……生生不息， 依賴不止， 記住一點(diǎn)： 只要做到抽象依賴， 即使是多層的依賴傳遞也無所畏懼！

對象的依賴關(guān)系有三種方式來傳遞， 如下所示。

1.構(gòu)造函數(shù)傳遞依賴對象

2.Setter方法傳遞依賴對象

3.接口聲明依賴對象

如何遵循這個(gè)原則：只要遵循以下的幾個(gè)規(guī)則就可以：

每個(gè)類盡量都有接口或抽象類， 或者抽象類和接口兩者都具備這是依賴倒置的基本要求， 接口和抽象類都是屬于抽象的， 有了抽象才可能依賴倒置绵患。 變量的表面類型盡量是接口或者是抽象類。

很多書上說變量的類型一定要是接口或者是抽象類管行， 這個(gè)有點(diǎn)絕對化了迅涮， 比如一個(gè)工具類， xxxUtils一般是不需要接口或是抽象類的朱盐。 還有， 如果你要使用類的clone方法， 就必須使用實(shí)現(xiàn)類， 這個(gè)是JDK提供的一個(gè)規(guī)范。 任何類都不應(yīng)該從具體類派生如果一個(gè)項(xiàng)目處于開發(fā)狀態(tài)泰佳， 確實(shí)不應(yīng)該有從具體類派生出子類的情況黔宛， 但這也不是絕對的积仗， 因?yàn)槿硕际菚?huì)犯錯(cuò)誤的漱挚， 有時(shí)設(shè)計(jì)缺陷是在所難免的白华， 因此只要不超過兩層的繼承都是可以忍受的管搪。 特別是負(fù)責(zé)項(xiàng)目維護(hù)的同志漂坏， 基本上可以不考慮這個(gè)規(guī)則塘慕， 為什么？ 維護(hù)工作基本上都是進(jìn)行擴(kuò)展開發(fā)， 修復(fù)行為， 通過一個(gè)繼承關(guān)系囤热， 覆寫一個(gè)方法就可以修正一個(gè)很大的Bug， 何必去繼承最高的基類呢？ （當(dāng)然這種情況盡量發(fā)生在不甚了解父類或者無法獲得父類代碼的情況下驯击。 ） 盡量不要覆寫基類的方法如果基類是一個(gè)抽象類主之， 而且這個(gè)方法已經(jīng)實(shí)現(xiàn)了， 子類盡量不要覆寫。

類間依賴的是抽象， 覆寫了抽象方法粒蜈， 對依賴的穩(wěn)定性會(huì)產(chǎn)生一定的影響寿冕。 結(jié)合里氏替換原則使用根據(jù)里氏替換原則， 父類出現(xiàn)的地方子類就能出現(xiàn)， 我們可以得出這樣一個(gè)通俗的規(guī)則： 接口負(fù)責(zé)定義public屬性和方法叶雹， 并且聲明與其他對象的依賴關(guān)系， 抽象類負(fù)責(zé)公共構(gòu)造部分的實(shí)現(xiàn)响驴， 實(shí)現(xiàn)類準(zhǔn)確的實(shí)現(xiàn)業(yè)務(wù)邏輯琳骡， 同時(shí)在適當(dāng)?shù)臅r(shí)候?qū)Ω割愡M(jìn)行細(xì)化藻懒。“倒置”不是倒過來什往，依賴正置就是類間的依賴是實(shí)實(shí)在在的實(shí)現(xiàn)類間的依賴， 也就是面向?qū)崿F(xiàn)編程。倒置坑鱼，就是面對具體的問題時(shí)证九，抽象出一個(gè)抽象的層甩鳄，即接口和抽象類，依賴倒置阿逃，就是依賴這些接口和抽象類

4 接口隔離原則

Interface Segregation Principle

規(guī)范的是類或接口的結(jié)構(gòu)， 強(qiáng)調(diào)接口的方法應(yīng)該盡可能的少

定義：

Clients should not be forced to depend upon interfaces that they don't use.（客戶端不應(yīng)該依賴它不需要的接口吴叶。 ） The dependency of one class to another one should depend on the smallest possible interface.（類間的依賴關(guān)系應(yīng)該建立在最小的接口上吭练。 ）把這兩個(gè)定義概括為一句話： 建立單一接口， 不要建立臃腫龐大的接口圆到。 再通俗一點(diǎn)講： 接口盡量細(xì)化， 同時(shí)接口中的方法盡量少耙饰。

接口隔離原則是對接口進(jìn)行規(guī)范約束， 其包含以下4層含義：

接口要盡量小枢冤。這是接口隔離原則的核心定義巍糯， 不出現(xiàn)臃腫的接口（Fat Interface） 咱筛， 但是“小”是有限度的撤蟆， 首先就是不能違反單一職責(zé)原則，根據(jù)接口隔離原則拆分接口時(shí)夕玩， 首先必須滿足單一職責(zé)原則彻磁。

接口要高內(nèi)聚什么置吓。是高內(nèi)聚告匠？ 高內(nèi)聚就是提高接口建瘫、 類匀们、 模塊的處理能力钟沛， 減少對外的交互。 比如你告訴下屬“到奧巴馬的辦公室偷一個(gè)×××文件”悠鞍， 然后聽到下屬用堅(jiān)定的口吻回答你： “是狞玛， 保證完成任務(wù)硬鞍！ ”一個(gè)月后伐坏， 你的下屬還真的把×××文件放到你的辦公桌上了， 這種不講任何條件、 立刻完成任務(wù)的行為就是高內(nèi)聚的表現(xiàn)狭郑。 具體到接口隔離原則就是， 要求在接口中盡量少公布public方法汇在， 接口是對外的承諾翰萨， 承諾越少對系統(tǒng)的開發(fā)越有利， 變更的風(fēng)險(xiǎn)也就越少糕殉， 同時(shí)也有利于降低成本亩鬼。

接口設(shè)計(jì)是有限度的。接口的設(shè)計(jì)粒度越小阿蝶， 系統(tǒng)越靈活雳锋， 這是不爭的事實(shí)。 但是羡洁， 靈活的同時(shí)也帶來了結(jié)構(gòu)的復(fù)雜化玷过， 開發(fā)難度增加， 可維護(hù)性降低筑煮， 這不是一個(gè)項(xiàng)目或產(chǎn)品所期望看到的辛蚊， 所以接口設(shè)計(jì)一定要注意適度。

實(shí)際意義：

接口隔離原則是對接口的定義真仲， 同時(shí)也是對類的定義袋马， 接口和類盡量使用原子接口或原子類來組裝。 但是秸应， 這個(gè)原子該怎么劃分是設(shè)計(jì)模式中的一大難題虑凛， 在實(shí)踐中可以根據(jù)以下幾個(gè)規(guī)則來衡量： 一個(gè)接口只服務(wù)于一個(gè)子模塊或業(yè)務(wù)邏輯； 通過業(yè)務(wù)邏輯壓縮接口中的public方法灸眼， 接口時(shí)常去回顧卧檐， 盡量讓接口達(dá)到“滿身筋骨肉”， 而不是“肥嘟嘟”的一大堆方法焰宣； 已經(jīng)被污染了的接口霉囚， 盡量去修改， 若變更的風(fēng)險(xiǎn)較大匕积， 則采用適配器模式進(jìn)行轉(zhuǎn)化處理盈罐； 了解環(huán)境榜跌， 拒絕盲從。 每個(gè)項(xiàng)目或產(chǎn)品都有特定的環(huán)境因素盅粪。

5 迪米特法則

Law of Demeter

強(qiáng)調(diào)的是類間的解耦钓葫，，高內(nèi)聚票顾，低耦合

?迪米特法則（Law of Demeter础浮， LoD） 也稱為最少知識(shí)原則（Least KnowledgePrinciple， LKP） 奠骄， 雖然名字不同豆同， 但描述的是同一個(gè)規(guī)則：

一個(gè)對象應(yīng)該對其他對象有最少的了解。

通俗地講含鳞， 一個(gè)類應(yīng)該對自己需要耦合或調(diào)用的類知道得最少影锈， 你（被耦合或調(diào)用的類） 的內(nèi)部是如何復(fù)雜都和我沒關(guān)系， 那是你的事情蝉绷， 我就知道你提供的這么多public方法鸭廷， 我就調(diào)用這么多， 其他的我一概不關(guān)心熔吗。迪米特法則對類的低耦合提出了明確的要求辆床， 其包含以下4層含義。

1. 只和朋友交流朋友類的定義是這樣的： 出現(xiàn)在成員變量磁滚、 方法的輸入輸出參數(shù)中的類稱為成員朋友類佛吓， 而出現(xiàn)在方法體內(nèi)部的類不屬于朋友類。

類與類之間的關(guān)系是建立在類間的垂攘， 而不是方法間维雇， 因此一個(gè)方法盡量不引入一個(gè)類中不存在的對象， 當(dāng)然晒他， JDK API提供的類除外吱型。

2. 朋友間也是有距離的。迪米特法則要求類“羞澀”一點(diǎn)陨仅， 盡量不要對外公布太多的public方法和非靜態(tài)的public變量津滞， 盡量內(nèi)斂， 多使用private灼伤、 package-private触徐、 protected等訪問權(quán)限。做一個(gè)穿長裙的姑娘狐赡，絕不穿比基尼

3. 是自己的就是自己的撞鹉。如果一個(gè)方法放在本類中， 既不增加類間關(guān)系， 也對本類不產(chǎn)生負(fù)面影響鸟雏， 那就放置在本類中享郊。

4. 謹(jǐn)慎使用Serializable。本地與遠(yuǎn)程端的修改不同步導(dǎo)致的迪米特法則的核心觀念就是類間解耦孝鹊， 弱耦合炊琉， 只有弱耦合了以后， 類的復(fù)用率才可以提高又活。 其要求的結(jié)果就是產(chǎn)生了大量的中轉(zhuǎn)或跳轉(zhuǎn)類苔咪， 導(dǎo)致系統(tǒng)的復(fù)雜性提高， 同時(shí)也為維護(hù)帶來了難度皇钞。 讀者在采用迪米特法則時(shí)需要反復(fù)權(quán)衡悼泌， 既做到讓結(jié)構(gòu)清晰， 又做到高內(nèi)聚低耦合夹界。

6 開閉原則

Open Closed Principle

此模式為設(shè)計(jì)模式的指導(dǎo)思想

開閉原則是Java世界里最基礎(chǔ)的設(shè)計(jì)原則， 它指導(dǎo)我們?nèi)绾谓⒁粋€(gè)穩(wěn)定的隘世、 靈活的系統(tǒng)可柿， 先來看開閉原則的定義：Software entities like classes,modules and functions should be open for extension but closed formodifications.（一個(gè)軟件實(shí)體如類、 模塊和函數(shù)應(yīng)該對擴(kuò)展開放丙者， 對修改關(guān)閉复斥。 ）一個(gè)軟件實(shí)體應(yīng)該通過擴(kuò)展來實(shí)現(xiàn)變化， 而不是通過修改已有的代碼來實(shí)現(xiàn)變化械媒。

軟件實(shí)體包括以下幾個(gè)部分： 項(xiàng)目或軟件產(chǎn)品中按照一定的邏輯規(guī)則劃分的模塊目锭。 抽象和類。 方法纷捞。

開閉原則對擴(kuò)展開放痢虹， 對修改關(guān)閉， 并不意味著不做任何修改主儡， 低層模塊的變更奖唯， 必然要有高層模塊進(jìn)行耦合， 否則就是一個(gè)孤立無意義的代碼片段糜值。前面五個(gè)原則都是開閉原則的具體形態(tài)丰捷，也就是說前五個(gè)原則就是指導(dǎo)設(shè)計(jì)的工具和方法， 而開閉原則才是其精神領(lǐng)袖寂汇。"Keep the bargreen to keep the code clean"如何實(shí)現(xiàn)開閉原則：

1. 抽象約束抽象是對一組事物的通用描述病往， 沒有具體的實(shí)現(xiàn)， 也就表示它可以有非常多的可能性骄瓣，可以跟隨需求的變化而變化停巷。

因此， 通過接口或抽象類可以約束一組可能變化的行為， 并且能夠?qū)崿F(xiàn)對擴(kuò)展開放叠穆， 其包含三層含義：

第一少漆， 通過接口或抽象類約束擴(kuò)展， 對擴(kuò)展進(jìn)行邊界限定硼被， 不允許出現(xiàn)在接口或抽象類中不存在的public方法示损；

第二， 參數(shù)類型嚷硫、 引用對象盡量使用接口或者抽象類检访， 而不是實(shí)現(xiàn)類；

第三仔掸， 抽象層盡量保持穩(wěn)定脆贵， 一旦確定即不允許修改。

2. 元數(shù)據(jù)（metadata） 控制模塊行為編程是一個(gè)很苦很累的活起暮， 那怎么才能減輕我們的壓力呢卖氨？ 答案是盡量使用元數(shù)據(jù)來控制程序的行為， 減少重復(fù)開發(fā)负懦。 什么是元數(shù)據(jù)筒捺？ 用來描述環(huán)境和數(shù)據(jù)的數(shù)據(jù)， 通俗地說就是配置參數(shù)纸厉， 參數(shù)可以從文件中獲得系吭， 也可以從數(shù)據(jù)庫中獲得。

3. 封裝變化對變化的封裝包含兩層含義：

第一颗品， 將相同的變化封裝到一個(gè)接口或抽象類中肯尺；

第二，將不同的變化封裝到不同的接口或抽象類中躯枢， 不應(yīng)該有兩個(gè)不同的變化出現(xiàn)在同一個(gè)接口或抽象類中则吟。 封裝變化， 也就是受保護(hù)的變化（protected variations） 闺金， 找出預(yù)計(jì)有變化或不穩(wěn)定的點(diǎn)逾滥， 我們?yōu)檫@些變化點(diǎn)創(chuàng)建穩(wěn)定的接口， 準(zhǔn)確地講是封裝可能發(fā)生的變化败匹， 一旦預(yù)測到或“第六感”發(fā)覺有變化寨昙， 就可以進(jìn)行封裝