介面隔離原則是什麼？

客戶端不應該依賴它不需要的介面；一個類別對另一個類別的依賴應該建立在最小的介面上。

使用多個專門的介面比使用單一的總介面好。

一個類別對另外一個類別的依賴性應是建立在最小的介面上的。

一個介面代表一個角色，不應當將不同的角色都交給一個介面。沒有關係的接口合併在一起，形成一個臃腫的大接口，這是對角色和接口的污染。

「不應該強迫客戶依賴它們不用的方法。介面屬於客戶，不屬於它所在的類別層次結構。」這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫使用者使用它們不使用的方法，那麼這些客戶就會面臨由於這些不使用的方法的改變所帶來的改變。

這個圖的意思是：類別A依賴介面I中的方法1、方法2、方法3，類別B是對類別A依賴的實作。類別C依賴介面I中的方法1、方法4、方法5，類別D是對類別C依賴的實作。對於類別B和類別D來說，雖然他們都存在著用不到的方法（也就是圖中紅色字體標記的方法），但由於實作了介面I，所以也必須實作這些用不到的方法。可以看到，如果介面太臃腫，只要介面中出現的方法，不管對依賴它的類別有沒有用處，實作類別中都必須去實作這些方法，這顯然不是好的設計。如果將這個設計修改為符合介面隔離原則，就必須將介面I進行拆分。在這裡我們將原有的接口I拆分為三個接口，拆分後的設計如圖所示

#接口隔離原則的意思是：建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少。也就是說，我們要為各個類別建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類別去調用。本文範例中，將一個龐大的介面變更為3個專用的介面所採用的就是介面隔離原則。在程式設計中，依賴幾個專用的介面要比依賴一個綜合的介面更靈活。接口是設計時對外部設定的“契約”，透過分散定義多個接口，可以預防外來變更的擴散，提高系統的靈活性和可維護性。

說到這裡，很多人會覺的介面隔離原則跟之前的單一職責原則很相似，其實不然。其一，單一職責原則原註重的是職責；而介面隔離原則注重對介面依賴的隔離。其二，單一職責原則主要是約束類，其次才是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序整體框架的構建。

採用介面隔離原則對介面進行約束時，要注意以下幾點：

介面盡量小，但是要有限度。對介面進行細化可以提高程式設計彈性是不掙的事實，但是如果過小，則會造成介面數量過多，使設計複雜化。所以一定要適量。

為依賴介面的類別自訂服務，只暴露給呼叫的類別它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模組提供客製化服務，才能建立最小的依賴關係。

提高內聚，減少對外互動。使介面用最少的方法去完成最多的事情。

運用介面隔離原則，一定要適度，介面設計的過大或過小都不好。設計介面的時候，只有多花點時間去思考、規劃，才能準確地實踐這項原則。

以上是介面隔離原則是什麼？的詳細內容。更多資訊請關注PHP中文網其他相關文章！