面向對象的7種設計原則(2)-接口隔離原則

定義

Interface Segregation Principle

• 客戶端不該依賴它不須要的接口

• 類間的依賴關係應該創建在最小的接口上

其實通俗來理解就是，不要在一個接口裏面放不少的方法，這樣會顯得這個類很臃腫。接口應該儘可能細化，一個接口對應一個功能模塊，同時接口裏面的方法應該儘量的少，使接口更加靈活輕便。或許有的人認爲接口隔離原則和單一職責原則很像，但兩個原則仍是存在着明顯的區別。單一職責原則是在業務邏輯上的劃分，注重的是職責。接口隔離原則是基於接口設計考慮。例如一個接口的職責包含10個方法，這10個方法都放在同一接口中，而且提供給多個模塊調用，但不一樣模塊須要依賴的方法是不同的，這時模塊爲了實現本身的功能就不得不實現一些對其沒有意義的方法，這樣的設計是不符合接口隔離原則的。接口隔離原則要求"儘可能使用多個專門的接口"專門提供給不一樣的模塊。

由來

類A經過接口I依賴類B，類C經過接口I依賴類D，若是接口I對於類A和類B來講不是最小接口，則類B和類D必須去實現他們不須要的方法。

舉例：

public interface School {

    /**
     * 上課
     */
    void attendClass();

    /**
     * 下課
     */
    void afterClass();

    /**
     * 學習
     */
    void learn();

    /**
     * 講課
     */
    void lecture();
}
複製代碼

假設此時有一個People類，它的角色是學生，實現了School接口。它就會被迫實現「講課」這個方法，事實它是不須要該方法的。這就形成了代碼的冗餘，使咱們的代碼變得臃腫。

解決

將臃腫的接口I拆分爲獨立的幾個接口，類A和類C分別與他們須要的接口創建依賴關係。

舉例： 學校接口

public interface School {

    /**
     * 上課
     */
    void attendClass();

    /**
     * 下課
     */
    void afterClass();

}
複製代碼

老師接口

public interface Teacher {

    /**
     * 講課
     */
    void lecture();
}
複製代碼

學生接口

public interface School {

    /**
     * 學習
     */
    void learn();

}
複製代碼

經過上面的拆分咱們就能夠有效避免冗餘代碼的產生，進而還能夠促使咱們的代碼變得更加靈活。

優勢

避免接口污染

一個類若是要實現一個接口，那麼就要實現這個接口要求的全部方法，若是這個接口裏麪包含這個類不須要的方法，那麼就會形成接口污染，這是很差的設計，會對系統留下隱患。

提升靈活性

一個類是能夠同時實現多個接口的，因此將一個臃腫的接口分割爲若干個小接口，經過小接口的不一樣組合能夠知足更多的需求。

提供定製服務

定製服務就是單獨爲一個個體提供優良的服務。咱們在作系統設計時也須要考慮對系統之間或模塊之間的接口提供定製服務。提供定製服務就必然有一個需求：只提供訪問者須要的方法。這也是能夠經過細化接口實現的。

高內聚

什麼是高內聚？高內聚就是提升接口、類、模塊的處理能力，減小對外的交互。好比說，你告訴你的下屬「一個小時以內去月球搬一塊石頭回來」，而後你就躺在海灘上曬着太陽喝着果汁，一個小時以後你的下屬就搬着一塊月亮上的石頭回來給你了。這種不講任何條件，不須要你關心任何細節，當即完成任務的行爲就是高內聚的表現。

具體到接口中，仍是儘可能細化你的接口。接口是對外界的承諾，承諾越少對系統的開發越有利，變動的風險也就越少，同時也有利於下降成本。

我的博客

騰訊雲社區

簡書

CSDN

公衆號：