作者：pdai
www.cnblogs.com/pengdai/p/9151800.html
在軟體開發中，前人對軟體系統的設計和開發總結了一些原則和模式， 不管用什么語言做開發，都將對我們系統設計和開發提供指導意義，本文主要將總結這些常見的原則，和具體闡述意義，
開發原則
面向物件的基本原則(solid)是五個，但是在經常被提到的除了這五個之外還有 迪米特法則和合成復用原則等， 所以在常見的文章中有表示寫六大或七大原則的； 除此之外我還將給出一些其它相關書籍和互聯網上出現的原則；
S單一職責SRP
Single-Responsibility Principle, 一個類,最好只做一件事,只有一個引起它的變化，單一職責原則可以看做是低耦合,高內聚在面向物件原則的引申,將職責定義為引起變化的原因,以提高內聚性減少引起變化的原因，
定義
一個物件應該只包含單一的職責，并且該職責被完整地封裝在一個類中，（Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.），即又定義有且僅有一個原因使類變更，點擊這里查看高可用架構設計9種方案詳解，
原則分析
-
一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的可能性越小，而且如果一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，
-
類的職責主要包括兩個方面：資料職責和行為職責，資料職責通過其屬性來體現，而行為職責通過其方法來體現，
-
單一職責原則是實作高內聚、低耦合的指導方針，在很多代碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗，
優點
-
降低類的復雜性，類的職責清晰明確，比如資料職責和行為職責清晰明確，
-
提高類的可讀性和維護性，
-
變更引起的風險減低，變更是必不可少的，如果介面的單一職責做得好，一個介面修改只對相應的類有影響，對其他介面無影響，這對系統的擴展性、維護性都有非常大的幫助，
注意：單一職責原則提出了一個撰寫程式的標準，用“職責”或“變化原因”來衡量介面或類設計得是否合理，但是“職責”和“變化原因”都是沒有具體標準的，一個類到底要負責那些職責？這些職責怎么細化？細化后是否都要有一個介面或類？這些都需從實際的情況考慮，因專案而異，因環境而異，
例子
SpringMVC 中Entity,DAO,Service,Controller, Util等的分離，
O開放封閉原則OCP
Open - ClosedPrinciple ,OCP, 對擴展開放，對修改關閉(設計模式的核心原則)
定義
一個軟體物體(如類、模塊和函式)應該對擴展開放，對修改關閉，意思是，在一個系統或者模塊中，對于擴展是開放的，對于修改是關閉的，一個 好的系統是在不修改源代碼的情況下，可以擴展你的功能，而實作開閉原則的關鍵就是抽象化，
原則分析
-
當軟體物體因需求要變化時, 盡量通過擴展已有軟體物體，可以提供新的行為，以滿足對軟體的新的需求，而不是修改已有的代碼，使變化中的軟體有一定的適應性和靈活性 ，已有軟體模塊，特別是最重要的抽象層模塊不能再修改，這使變化中的軟體系統有一定的穩定性和延續性，
-
實作開閉原則的關鍵就是抽象化 :在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴展的是具體的實作類,抽象類和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴展..所以在這里"抽象化"是關鍵!
-
可變性的封閉原則:找到系統的可變因素,將它封裝起來. 這是對"開-閉"原則最好的實作. 不要把你的可變因素放在多個類中,或者散落在程式的各個角落. 你應該將可變的因素,封套起來..并且切忌不要把所用的可變因素封套在一起. 最好的解決辦法是,分塊封套你的可變因素!避免超大類,超長類,超長方法的出現!!給你的程式增加藝術氣息,將程式藝識訓是我們的目標!
例子
設計模式中模板方法模式和觀察者模式都是開閉原則的極好體現，點擊這里查看高可用架構設計9種方案詳解，
L里氏替換原則LSP
Liskov Substitution Principle，LSP：任何基類可以出現的地方，子類也可以出現；這一思想表現為對繼承機制的約束規范，只有子類能夠替換其基類時，才能夠保證系統在運行期內識別子類，這是保證繼承復用的基礎，
定義
第一種定義方式相對嚴格：如果對每一個型別為S的物件o1，都有型別為T的物件o2，使得以T定義的所有程式P在所有的物件o1都代換成o2時，程式P的行為沒有變化，那么型別S是型別T的子型別，
第二種更容易理解的定義方式：所有參考基類（父類）的地方必須能透明地使用其子類的物件，即子類能夠必須能夠替換基類能夠從出現的地方，子類也能在基類 的基礎上新增行為，
（里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士、麻省理工學院教授BarbaraLiskov和卡內基.梅隆大學Jeannette Wing教授于1994年提出，其原文如下：Let q(x) be a property provableabout objects x of type T. Then q(y) should be true for objects y of type Swhere S is a subtype of T. ）
原則分析
-
講的是基類和子類的關系，只有這種關系存在時，里氏代換原則才存在，正方形是長方形是理解里氏代換原則的經典例子，
-
里氏代換原則可以通俗表述為：在軟體中如果能夠使用基類物件，那么一定能夠使用其子類物件，把基類都替換成它的子類，程式將不會產生任何錯誤和例外，反過來則不成立，如果一個軟體物體使用的是一個子類的話，那么它不一定能夠使用基類，
-
里氏代換原則是實作開閉原則的重要方式之一，由于使用基類物件的地方都可以使用子類物件，因此在程式中盡量使用基型別別來對物件進行定義，而在運行時再確定其子型別別，用子類物件來替換父類物件，
I介面隔離法則
(Interface Segregation Principle，ISL）：客戶端不應該依賴那些它不需要的介面，（這個法則與迪米特法則是相通的）
定義
客戶端不應該依賴那些它不需要的介面，
另一種定義方法：一旦一個介面太大，則需要將它分割成一些更細小的介面，使用該介面的客戶端僅需知道與之相關的方法即可，
注意，在該定義中的介面指的是所定義的方法，例如外面呼叫某個類的public方法，這個方法對外就是介面，
原則分析
1）介面隔離原則是指使用多個專門的介面，而不使用單一的總介面，每一個介面應該承擔一種相對獨立的角色，不多不少，不干不該干的事，該干的事都要干，
-
一個介面就只代表一個角色，每個角色都有它特定的一個介面，此時這個原則可以叫做“角色隔離原則”，
-
介面僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的介面，而不要提供大的總介面，
2）使用介面隔離原則拆分介面時，首先必須滿足單一職責原則，將一組相關的操作定義在一個介面中，且在滿足高內聚的前提下，介面中的方法越少越好，
3）可以在進行系統設計時采用定制服務的方式，即為不同的客戶端提供寬窄不同的介面，只提供用戶需要的行為，而隱藏用戶不需要的行為，
D依賴倒置原則DIP
Dependency-Inversion Principle 要依賴抽象，而不要依賴具體的實作，具體而言就是高層模塊不依賴于底層模塊，二者共同依賴于抽象，抽象不依賴于具體，具體依賴于抽象，
定義
高層模塊不應該依賴低層模塊，它們都應該依賴抽象，抽象不應該依賴于細節，細節應該依賴于抽象，簡單的說，依賴倒置原則要求客戶端依賴于抽象耦合，原則表述：
1）抽象不應當依賴于細節；細節應當依賴于抽象；
2）要針對介面編程，不針對實作編程，
原則分析
1）如果說開閉原則是面向物件設計的目標，依賴倒轉原則是到達面向設計"開閉"原則的手段，如果要達到最好的"開閉"原則，就要盡量的遵守依賴倒轉原則，可以說依賴倒轉原則是對“抽象化”的最好規范！我個人感覺，依賴倒轉原則也是里氏代換原則的補充，你理解了里氏代換原則，再來理解依賴倒轉原則應該是很容易的，
2）依賴倒轉原則的常用實作方式之一是在代碼中使用抽象類，而將具體類放在組態檔中，
3）類之間的耦合：零耦合關系，具體耦合關系，抽象耦合關系，依賴倒轉原則要求客戶端依賴于抽象耦合，以抽象方式耦合是依賴倒轉原則的關鍵，
例子
理解這個依賴倒置，首先我們需要明白依賴在面向物件設計的概念：
依賴關系(Dependency)：是一種使用關系，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關系，（假設A類的變化引起了B類的變化，則說名B類依賴于A類，）大多數情況下，依賴關系體現在某個類的方法使用另一個類的物件作為引數，在UML中，依賴關系用帶箭頭的虛線表示，由依賴的一方指向被依賴的一方，
例子：某系統提供一個資料轉換模塊，可以將來自不同資料源的資料轉換成多種格式，如可以轉換來自資料庫的資料(DatabaseSource)、也可以轉換來自文本檔案的資料(TextSource)，轉換后的格式可以是XML檔案(XMLTransformer)、也可以是XLS檔案(XLSTransformer)等，
由于需求的變化，該系統可能需要增加新的資料源或者新的檔案格式，每增加一個新的型別的資料源或者新的型別的檔案格式，客戶類MainClass都需要修改源代碼，以便使用新的類，但違背了開閉原則，現使用依賴倒轉原則對其進行重構，點擊這里查看高可用架構設計9種方案詳解，
- 當然根據具體的情況，也可以將AbstractSource注入到AbstractStransformer，依賴注入的方式有以下三種：
/**
* 依賴注入是依賴AbstractSource抽象注入的，而不是具體
* DatabaseSource
*
*/
abstract class AbstractStransformer {
private AbstractSource source;
/**
* 構造注入(Constructor Injection)：通過建構式注入實體變數，
*/
public void AbstractStransformer(AbstractSource source){
this.source = source;
}
/**
* 設值注入(Setter Injection)：通過Setter方法注入實體變數，
* @param source : the sourceto set
*/
public void setSource(AbstractSource source) {
this.source = source;
}
/**
* 介面注入(Interface Injection)：通過介面方法注入實體變數，
* @param source
*/
public void transform(AbstractSource source ) {
source.getSource();
System.out.println("Stransforming ...");
}
}
合成/聚合復用原則
(Composite/Aggregate ReusePrinciple ，CARP)：要盡量使用物件組合,而不是繼承關系達到軟體復用的目的
定義
經常又叫做合成復用原則（Composite ReusePrinciple或CRP），盡量使用物件組合，而不是繼承來達到復用的目的，
就是在一個新的物件里面使用一些已有的物件，使之成為新物件的一部分；新物件通過向這些物件的委派達到復用已有功能的目的，簡而言之，要盡量使用合成/聚合，盡量不要使用繼承，
原則分析
1）在面向物件設計中，可以通過兩種基本方法在不同的環境中復用已有的設計和實作，即通過組合/聚合關系或通過繼承，
繼承復用：實作簡單，易于擴展，破壞系統的封裝性；從基類繼承而來的實作是靜態的，不可能在運行時發生改變，沒有足夠的靈活性；只能在有限的環境中使用，（“白箱”復用）
組合/聚合復用：耦合度相對較低，選擇性地呼叫成員物件的操作；可以在運行時動態進行，（“黑箱”復用）
2）組合/聚合可以使系統更加靈活，類與類之間的耦合度降低，一個類的變化對其他類造成的影響相對較少，因此一般首選使用組合/聚合來實作復用；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助于對問題的理解，降低復雜度，而濫用繼承反而會增加系統構建和維護的難度以及系統的復雜度，因此需要慎重使用繼承復用，
3）此原則和里氏代換原則氏相輔相成的,兩者都是具體實作"開-閉"原則的規范，違反這一原則，就無法實作"開-閉"原則，首先我們要明白合成和聚合的概念：
注意：聚合和組合的區別是什么？
合成（組合）：表示一個整體與部分的關系，指一個依托整體而存在的關系（整體與部分不可以分開）；比如眼睛和嘴對于頭來說就是組合關系，沒有了頭就沒有眼睛和嘴，它們是不可分割的，在UML中，組合關系用帶實心菱形的直線表示，
聚合：聚合是比合成關系的一種更強的依賴關系，也表示整體與部分的關系（整體與部分可以分開）；比如螺絲和汽車玩具的關系，螺絲脫離玩具依然可以用在其它設備之上，在UML中，聚合關系用帶空心菱形的直線表示，
迪米特法則
(Law of Demeter，LoD：系統中的類，盡量不要與其他類互相作用，減少類之間的耦合度
定義
又叫最少知識原則（Least Knowledge Principle或簡寫為LKP）幾種形式定義：
-
不要和“陌生人”說話，英文定義為：Don't talk to strangers.
-
只與你的直接朋友通信，英文定義為：Talk only to your immediate friends.
-
每一個軟體單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關的軟體單位，
簡單地說，也就是，一個物件應當對其它物件有盡可能少的了解，一個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或呼叫的類）的內部是如何復雜都和我沒關系，那是你的事情，我就知道你提供的public方法，我就呼叫這么多，其他的一概不關心，
法則分析
- 朋友類：
在迪米特法則中，對于一個物件，其朋友包括以下幾類： (1) 當前物件本身(this)； (2) 以引數形式傳入到當前物件方法中的物件； (3) 當前物件的成員物件； (4) 如果當前物件的成員物件是一個集合，那么集合中的元素也都是朋友；(5) 當前物件所創建的物件，
任何一個物件，如果滿足上面的條件之一，就是當前物件的“朋友”，否則就是“陌生人”，
- 狹義法則和廣義法則：
在狹義的迪米特法則中，如果兩個類之間不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用，如果其中的一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫，
狹義的迪米特法則：可以降低類之間的耦合，但是會在系統中增加大量的小方法并散落在系統的各個角落，它可以使一個系統的區域設計簡化，因為每一個區域都不會和遠距離的物件有直接的關聯，但是也會造成系統的不同模塊之間的通信效率降低，使得系統的不同模塊之間不容易協調，點擊這里查看高可用架構設計9種方案詳解，
廣義的迪米特法則：指對物件之間的資訊流量、流向以及資訊的影響的控制，主要是對資訊隱藏的控制，資訊的隱藏可以使各個子系統之間脫耦，從而允許它們獨立地被開發、優化、使用和修改，同時可以促進軟體的復用，由于每一個模塊都不依賴于其他模塊而存在，因此每一個模塊都可以獨立地在其他的地方使用，一個系統的規模越大，資訊的隱藏就越重要，而資訊隱藏的重要性也就越明顯，
-
迪米特法則的主要用途：在于控制資訊的過載，
-
在類的劃分上，應當盡量創建松耦合的類，類之間的耦合度越低，就越有利于復用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；
-
在類的結構設計上，每一個類都應當盡量降低其成員變數和成員函式的訪問權限；
-
在類的設計上，只要有可能，一個型別應當設計成不變類；
-
在對其他類的參考上，一個物件對其他物件的參考應當降到最低，
例子
外觀模式Facade（結構型）
迪米特法則與設計模式Facade模式、Mediator模式
系統中的類，盡量不要與其他類互相作用，減少類之間的耦合度，因為在你的系統中，擴展的時候，你可能需要修改這些類，而類與類之間的關系，決定了修改的復雜度，相互作用越多，則修改難度就越大，反之，如果相互作用的越小，則修改起來的難度就越小，例如A類依賴B類，則B類依賴C類，當你在修改A類的時候，你要考慮B類是否會受到影響，而B類的影響是否又會影響到C類， 如果此時C類再依賴D類的話，呵呵，我想這樣的修改有的受了，
Q&A
面向物件設計其他原則
封裝變化
少用繼承 多用組合
針對介面編程 不針對實作編程
為互動物件之間的松耦合設計而努力
類應該對擴展開發 對修改封閉（開閉OCP原則）
依賴抽象，不要依賴于具體類（依賴倒置DIP原則）
密友原則：只和朋友交談（最少知識原則，迪米特法則）
說明：一個物件應當對其他物件有盡可能少的了解，將方法呼叫保持在界限內，只呼叫屬于以下范圍的方法： 該物件本身（本地方法）物件的組件 被當作方法引數傳進來的物件 此方法創建或實體化的任何物件
別找我（呼叫我） 我會找你（呼叫你）（好萊塢原則）
一個類只有一個引起它變化的原因（單一職責SRP原則）
你能解釋一下里氏替換原則嗎?
嚴格定義：如果對每一個型別為S的物件o1，都有型別為T的物件o2，使得以T定義的所有程式P在所有的物件用o1替換o2時，程式P的行為沒有變化，那么型別S是型別T的子型別，
通俗表述：所有參考基類（父類）的地方必須能透明地使用其子類的物件，也就是說子類可以擴展父類的功能，但不能改變父類原有的功能，它包含以下4層含義：
子類可以實作父類的抽象方法，但不能覆寫父類的非抽象方法，
子類中可以增加自己特有的方法，
當子類的方法多載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬松，
當子類的方法實作父類的抽象方法時，方法的后置條件（即方法的回傳值）要比父類更嚴格，
什么情況下會違反迪米特法則？為什么會有這個問題？
迪米特法則建議“只和朋友說話，不要陌生人說話”，以此來減少類之間的耦合，
給我一個符合開閉原則的設計模式的例子？
開閉原則要求你的代碼對擴展開放，對修改關閉，這個意思就是說，如果你想增加一個新的功能，你可以很容易的在不改變已測驗過的代碼的前提下增加新的代碼，有好幾個設計模式是基于開閉原則的，如策略模式，如果你需要一個新的策略，只需要實作介面，增加配置，不需要改變核心邏輯，一個正在作業的例子是 Collections.sort() 方法，這就是基于策略模式，遵循開閉原則的，你不需為新的物件修改 sort() 方法，你需要做的僅僅是實作你自己的 Comparator 介面，
什么時候使用享元模式（蠅量模式）？
享元模式通過共享物件來避免創建太多的物件，為了使用享元模式，你需要確保你的物件是不可變的，這樣你才能安全的共享，JDK 中 String 池、Integer 池以及 Long 池都是很好的使用了享元模式的例子，
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/179251.html
標籤：Java
上一篇：多執行緒：（優先級、守護執行緒）