1、單一原則

一個類只負責一個功能領域的相應職責，或者可以定義為，就一個類而言，應該只有一個引起它變化的原因。?

? ? ? ?單一原則的實現，完全取決于你這么抽象的看待這個問題，你抽象的合適，那么它可以很棒，如果抽象的不夠，它可能就是臃腫的類，抽象的過多，有可能創造出一大把寄生類。 單一職責原則這話就像我們常聽的那句"做人要堅持"。聽起來無懈可擊，但是要堅持什么呢，如果這事情看起來不靠譜，做著難受，我還該不該堅持呢，所以'做人要堅持'是句營養不是很足的廢話。

? ? ? ?單一職責這話也有那么點意思。 但既然單一職責被放到設計模式的第一位，自然有其道理。所以單一模式真正的目的，其實也是設計模式的一大目的之一就是降低開發人員的腦力棧的消耗。 人腦比起電腦，沒有那么深那么多得棧，所以我們在一個較短的時間內，能理解的東西是有限的，如果一次性灌輸太多事務，超過其瞬時腦容量，基本后面再思考的時候就雪崩了，所以單一職責最大的準則，就是讀起來越輕松越好。 而所謂讀起來越輕松越好，說得比較官方一點就是：使這個類改變的因數只有唯一的一個時，那么這個類符合單一原則。

?

2、開閉原則

軟件實現應該對擴展開放，對修改關閉

一個軟件產品只要在生命周期內，都會發生變化，即然變化是一個事實，我們就應該在設計時盡量適應這些變化，以提高項目的穩定性和靈活性，真正實現“擁抱變化”。開閉原則告訴我們應盡量通過擴展軟件實體的行為來實現變化，而不是通過修改現有代碼來完成變化，它是為軟件實體的未來事件而制定的對現行開發設計進行約束的一個原則。

第一：抽象約束?
抽象是對一組事物的通用描述，沒有具體的實現，也就表示它可以有非常多的可能性，可以跟隨需求的變化而變化。因此，通過接口或抽象類可以約束一組可能變化的行為，并且能夠實現對擴展開放，其包含三層含義：

• 通過接口或抽象類約束擴散，對擴展進行邊界限定，不允許出現在接口或抽象類中不存在的public方法。
• 參數類型，引用對象盡量使用接口或抽象類，而不是實現類，這主要是實現里氏替換原則的一個要求
• 抽象層盡量保持穩定，一旦確定就不要修改

第二：元數據(metadata)控件模塊行為?
編程是一個很苦很累的活，那怎么才能減輕壓力呢？答案是盡量使用元數據來控制程序的行為，減少重復開發。什么是元數據？用來描述環境和數據的數據，通俗的說就是配置參數，參數可以從文件中獲得，也可以從數據庫中獲得，同時也應該考慮數據庫表的通用性和擴張性

第三：制定項目章程?
在一個團隊中，建立項目章程是非常重要的，因為章程是所有人員都必須遵守的約定，對項目來說，約定優于配置。這比通過接口或抽象類進行約束效率更高，而擴展性一點也沒有減少。

第四：封裝變化?
對變化封裝包含兩層含義：?
(1)將相同的變化封裝到一個接口或抽象類中?
(2)將不同的變化封裝到不同的接口或抽象類中，不應該有兩個不同的變化出現在同一個接口或抽象類中。?
封裝變化，也就是受保護的變化，找出預計有變化或不穩定的點，我們為這些變化點創建穩定的接口。

?

3、伯斯塔爾原則

?按照伯斯塔爾法則的思想來設計實現服務調用時，發送的數據要更保守，意味著最小化的傳送必要的信息，接收時更開放意味著要最大限度的容忍信息的兼容性。?多余的信息不認識可以忽略，而不應該拒絕或拋出錯誤。?

?

4、里氏替換原則

所有引用父類的地方，必須能透明的使用其子類對象

父類的一個方法的返回值是一個類型T，子類的相同方法的返回值為S，那么里氏替換原則就要求S必須小于等于T。采用里氏替換原則的目的就是增強程序的健壯性，版本升級時也可以保持非常好的兼容性。即使增加子類，原有的子類還可以繼續運行。在實際項目中，每個子類對應不同的業務含義，使用父類作為參數，傳遞不同的子類完成不同的業務邏輯，非常完美。

?

5、接口隔離原則

使用多個專門的接口，而不使用單一的總接口。 其實接口隔離原則說白了就是單一職責的擴展，或者說細化，將單一的概念擴展至接口，或者說具體的函數。對于一個個比較細化的接口，優點簡潔且明顯，那就是更小的接口，更有利于書寫單元測試，也更有利于調試。

?

而如果能有比較多專門的接口，無疑會極大降低閱讀理解代碼的成本，閱讀者往往只需要了解任務的分發邏輯就好，不需要一不小心就沉到底層繁瑣的邏輯中，一個大的接口在閱讀的時候，往往是任務分發邏輯和任務執行邏輯嚴重耦合在一起的，當你以為你在了解任務分發部分的邏輯的時候，你可能已經在讀具體業務處理邏輯了。然而其實往往你根本不需要關系具體的某個功能的邏輯，多數時候，你只是需要修改一點分發邏輯。這個時候細粒度的接口就體現出優點，更為細粒度的接口，有利于隔離業務處理和業務分發的邏輯，可以提高閱讀代碼效率。不要小瞧這點，試想一個團隊招來的新人，全部都在解決老坑的路上步履蹣跚，拖累了開發新功能進度，而這些老的東西很難再創造價值了，而能創造價值的東西，卻總是在拖延中，拖過了市場，再來價值就縮水的厲害了。

?

6、合成復用原則

優先使用組合而不是繼承。繼承必須在is-a的關系成立的時候才能使用，否則使用組合，之所以不使用繼承，是因為繼承會將基類的實現細節暴露給子類，這個就導致如果基類發生改變，那么子類也不得不改變，相對而言，使用組合，可以有更好的封裝性。

?

7、依賴倒置原則

抽象不依賴于細節，細節應該依賴于抽象。

在實現依賴倒轉的原則的時候，我們最常使用的技術就是依賴注入（Dependency Injection,DI),通過依賴注入來對一個抽象的對象注入一個具體的實例。 對于設計模式來說，盡可能的開閉是目標，里氏替換是實現開閉的基礎，而依賴倒轉是具體的手段。

?

8、迪米特法則

一個軟件實體應當盡可能少的與其它實體發生相互作用。 最能體現這種思想是中介者模式，在中介者模式中，各個對象之間存在通信，但是對象之間并不會互相引用，而是維持一個中介者的引用，當我們需要添加一個成員的時候，我們往往增加一個對象再修改一下中介者就好了，大部分的時候，其它對象是無感知的。 迪米特法則的好處，在于滿足迪米特法則的類，通常都是可測試的類。不過想寫出這樣的類可不容易，這個時候可以考慮TDD的方法，不過這就是另一個話題了。

總結

以上是生活随笔為你收集整理的接口设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。