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è)計模式之禪》