設計模式六大原則： 接口隔離原則

我的女朋友小肉是一名光榮的輔導班老師，說來慚愧，我上初中那會兒最討厭輔導班老師了，每天上學都這麼累了，晚上還得去見輔導班老師，神煩，奈何目前的教育機制下，很多家長認為輔導班是提高成績比較靠譜的方式，導致這個行業市場很大。

小肉教三個水平不同的小班，那天看她在准備講義和試題，同一章內容需要做三份，其中很多內容都是重復的，自诩設計模式略懂一二的我跟她說：

你這個講義跟我敲代碼很像，相似的內容這麼多，直接復制粘貼容易出問題啊，還不如把公共的部分提一個接口，然後讓三種水平的講義都實現這個接口

比如這樣：

教案接口，指定所有班級要做的事：

/**
 * 教案接口，指定共同內容
 */
public interface TeachingPlanImpl {
    /**
     * 教授基礎知識
     */
    void teachBaseKnowledge();

    /**
     * 教授拓展知識
     */
    void teachExtraKnowledge();

    /**
     * 教授拔高知識
     */
    void teachComplexKnowledge();

    /**
     * 布置簡單作業
     */
    void assignBaseHomeWork();

    /**
     * 布置提升作業
     */
    void assignExtraHomeWork();

    /**
     * 布置復雜作業
     */
    void assignComplexHomeWork();
}

然後讓三個班級的講義實現這個接口：

/**
 * 基礎班教案
 * Created by zhangshixin on 8/15/2016.
 */
public class TeachPlanBase implements TeachingPlanImpl {
    @Override
    public void teachBaseKnowledge() {

    }

    @Override
    public void teachExtraKnowledge() {

    }

    @Override
    public void teachComplexKnowledge() {

    }

    @Override
    public void assignBaseHomeWork() {

    }

    @Override
    public void assignExtraHomeWork() {

    }

    @Override
    public void assignComplexHomeWork() {

    }
}

//其余兩個拔高班 TeachPlanExtra 、奧數班 TeachPlanComplex 教案類似，不再列舉

這樣你有需要改動的時候修改一處就好了，多省勁啊哈哈（得意臉）

沒想到肉肉說：

可是普通班的孩子只要掌握基礎就好了啊，他們要是發現自己不會的那麼多該多難受 T.T 。基礎班的只要基礎知識和題，拓展班也不需要做奧數啊。而且哦，萬一我的模板教案打錯了，一下次還影響了三個班級的孩子。

沒有好處反而有可能帶來壞處，我覺得你設計的不好！

.

你！！ 好吧，我竟無言以對

抽象、封裝，不是要把公共的都提出去嗎？帶著疑問我開始求醫問藥，直到發現了：

接口隔離原則 ISP (Interface Segregation Principle)

定義：

客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
接口應該是內聚的，應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。

接口存在就是為了把細節和抽象分離開來，但是如果一個接口抽象的內容太多，其實就等於沒有抽象。一個過於臃腫的接口會給它的實現類帶來很多壓力，比如上述例子講的教案問題，對胖接口的修改會影響到很多實現類，有時候可能會帶來大麻煩。

正確的方法是將胖接口分割成幾個小接口，因材施教，不要給客戶端暴露不需要的接口。

這裡比較糾結的是接口究竟怎麼算大，怎麼算小，接口隔離原則也沒有告訴我們，我們需要注意的就是接口的實現類盡量少實現不需要的方法，至於那個度還需要自己把握。

總結：一個諸葛亮不如 N 個裨將，萬一諸葛亮病了呢

還容易混淆的是 單一職責原則和接口隔離原則的區別？

接口隔離原則強調的是設計時的架構分離，把不同功能分給不同的接口，讓實現類避免少了解與己無關的方法、通過實現不同接口保證與外部的耦合； 單一職責原則強調的是 實現時的職責分離，具體功能下的不同實現要封裝在不同的模塊，盡量避免牽一發而動全身。