本文轉自：http://www.cnblogs.com/pengdai/p/9151800.html

在軟體開發中，前人對軟體系統的設計和開發總結了一些原則和模式， 不管用什麼語言做開發，都將對我們系統設計和開發提供指導意義。本文主要將總結這些常見的原則，和具體闡述意義。 -----2018年1月 @pdai

參考文章

開發原則

面向物件的基本原則(solid)是五個，但是在經常被提到的除了這五個之外還有 迪米特法則和合成複用原則等， 所以在常見的文章中有表示寫六大或七大原則的； 除此之外我還將給出一些其它相關書籍和網際網路上出現的原則；

S單一職責SRP

Single-Responsibility Principle, 一個類,最好只做一件事,只有一個引起它的變化。單一職責原則可以看做是低耦合,高內聚在面向物件原則的引申,將職責定義為引起變化的原因,以提高內聚性減少引起變化的原因。

定義

一個物件應該只包含單一的職責，並且該職責被完整地封裝在一個類中。（Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.），即又定義有且僅有一個原因使類變更。

原則分析

• 一個類（或者大到模組，小到方法）承擔的職責越多，它被複用的可能性越小，而且如果一個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作。
• 類的職責主要包括兩個方面：資料職責和行為職責，資料職責通過其屬性來體現，而行為職責通過其方法來體現。
• 單一職責原則是實現高內聚、低耦合的指導方針，在很多程式碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。

優點

• 降低類的複雜性，類的職責清晰明確。比如資料職責和行為職責清晰明確。
• 提高類的可讀性和維護性，
• 變更引起的風險減低，變更是必不可少的，如果介面的單一職責做得好，一個介面修改只對相應的類有影響，對其他介面無影響，這對系統的擴充套件性、維護性都有非常大的幫助。

注意：單一職責原則提出了一個編寫程式的標準，用“職責”或“變化原因”來衡量介面或類設計得是否合理，但是“職責”和“變化原因”都是沒有具體標準的，一個類到底要負責那些職責？這些職責怎麼細化？細化後是否都要有一個介面或類？這些都需從實際的情況考慮。因專案而異，因環境而異。

例子

SpringMVC 中Entity,DAO,Service,Controller, Util等的分離。

O開放封閉原則OCP

Open - ClosedPrinciple ,OCP, 對擴充套件開放，對修改關閉(設計模式的核心原則)

定義

一個軟體實體(如類、模組和函式)應該對擴充套件開放，對修改關閉. 意思是,在一個系統或者模組中,對於擴充套件是開放的,對於修改是關閉的,一個 好的系統是在不修改原始碼的情況下,可以擴充套件你的功能. 而實現開閉原則的關鍵就是抽象化.

原則分析 :

• 當軟體實體因需求要變化時, 儘量通過擴充套件已有軟體實體，可以提供新的行為，以滿足對軟體的新的需求，而不是修改已有的程式碼，使變化中的軟體有一定的適應性和靈活性 。已有軟體模組，特別是最重要的抽象層模組不能再修改，這使變化中的軟體系統有一定的穩定性和延續性。

• 實現開閉原則的關鍵就是抽象化 :在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充套件的是具體的實現類,抽象類和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴充套件..所以在這裡"抽象化"是關鍵!

• 可變性的封閉原則:找到系統的可變因素,將它封裝起來. 這是對"開-閉"原則最好的實現. 不要把你的可變因素放在多個類中,或者散落在程式的各個角落. 你應該將可變的因素,封套起來..並且切忌不要把所用的可變因素封套在一起. 最好的解決辦法是,分塊封套你的可變因素!避免超大類,超長類,超長方法的出現!!給你的程式增加藝術氣息,將程式藝術化是我們的目標!

例子

設計模式中模板方法模式和觀察者模式都是開閉原則的極好體現。

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都需要修改原始碼，以便使用新的類，但違背了開閉原則。現使用依賴倒轉原則對其進行重構。

• 當然根據具體的情況，也可以將AbstractSource注入到AbstractStransformer，依賴注入的方式有以下三種：

/**  * 依賴注入是依賴AbstractSource抽象注入的，而不是具體  * DatabaseSource  *  */  
abstract class AbstractStransformer {  
    private AbstractSource source;   
    /**      * 構造注入(Constructor Injection)：通過建構函式注入例項變數。      */  
    publicvoidAbstractStransformer(AbstractSource source){  
        this.source = source;           
    }  
    /**           * 設值注入(Setter Injection)：通過Setter方法注入例項變數。      * @param source : the sourceto set             */       
    publicvoidsetSource(AbstractSource source) {            
        this.source = source;             
    }  
    /**      * 介面注入(Interface Injection)：通過介面方法注入例項變數。      * @param source      */  
    publicvoidtransform(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) 當前物件所建立的物件。
  任何一個物件，如果滿足上面的條件之一，就是當前物件的“朋友”，否則就是“陌生人”。

• 狹義法則和廣義法則：
  在狹義的迪米特法則中，如果兩個類之間不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用，如果其中的一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫。

  狹義的迪米特法則：可以降低類之間的耦合，但是會在系統中增加大量的小方法並散落在系統的各個角落，它可以使一個系統的區域性設計簡化，因為每一個區域性都不會和遠距離的物件有直接的關聯，但是也會造成系統的不同模組之間的通訊效率降低，使得系統的不同模組之間不容易協調。
  廣義的迪米特法則：指對物件之間的資訊流量、流向以及資訊的影響的控制，主要是對資訊隱藏的控制。資訊的隱藏可以使各個子系統之間脫耦，從而允許它們獨立地被開發、優化、使用和修改，同時可以促進軟體的複用，由於每一個模組都不依賴於其他模組而存在，因此每一個模組都可以獨立地在其他的地方使用。一個系統的規模越大，資訊的隱藏就越重要，而資訊隱藏的重要性也就越明顯。

• 迪米特法則的主要用途：在於控制資訊的過載。
  •在類的劃分上，應當儘量建立鬆耦合的類，類之間的耦合度越低，就越有利於複用，一個處在鬆耦合中的類一旦被修改，不會對關聯的類造成太大波及；
  •在類的結構設計上，每一個類都應當儘量降低其成員變數和成員函式的訪問許可權；
  •在類的設計上，只要有可能，一個型別應當設計成不變類；
  •在對其他類的引用上，一個物件對其他物件的引用應當降到最低。

例子

外觀模式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 介面。

相關推薦