嘻哈說：設計模式之接口隔離原則

一、定義

按照慣例，首先咱們來看一下接口隔離原則的定義。

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

接口中的方法應該儘可能少，不要使接口過於臃腫，不要有不少不相關的邏輯方法。

有點相似於單一職責原則，都是功能儘量的簡單單一，不要冗餘太多其餘不相關的。

單一職責原則主要是類與方法，而接口隔離原則倒是對接口而言的。

二、場景

小廚洗菜，大廚作飯。

在番茄餐廳的後廚，老闆與求生欲極強的廚師長在聊天。

老闆：最近咱們番茄餐廳廣受好評，菜品味道美味，這還得感謝你這位廚師長呀。

廚師長：應該的，這該感謝我。

老闆：嗯？你肯定？

廚師長：還沒，還沒說完，這該感謝我...們的郝老闆，此次肯定了。（冷汗）

老闆：你這求生欲厲害了，歎爲觀止呀。不過如今隨着顧客的增多，人手再次不夠了，再招廚師確定來不及了，你有什麼好辦法嗎？

廚師長：辦法我還真有一個，咱們能夠招點小廚，小廚要好招一些。

老闆：但小廚作飯不夠美味，很容易流失客戶的。

廚師長：小廚不作飯，小廚只負責洗菜。這樣呢，大廚就不用洗菜了，只負責作飯，這樣效率就上去了。

老闆：你是否是不想洗菜？

廚師長：固然不是，我就是，就是，就是替公司着想。

老闆：好吧，準了，招人吧。

三、代碼

以前咱們在依賴倒置原則聊過對接口編程，因此，首先咱們定義一個廚師接口。

package com.fanqiekt.principle.segregation;

/**
 * 廚師接口
 *
 * @author 番茄課堂-懶人
 */
public interface IChef {

    /**
     * 洗菜
     */
    void wash();

    /**
     * 作飯
     */
    void cooking();
}
複製代碼

廚師作兩件事，一個是洗菜，一個是作菜。

接下來，咱們寫一下大廚的代碼，大廚實現了廚師接口。

大廚作飯，但不負責洗菜。

package com.fanqiekt.principle.segregation;

/**
 * 大廚
 *
 * @author 番茄課堂-懶人
 */
public class BigChef implements IChef {

    /**
     * 洗菜的邏輯與大廚無關
     */
    @Override
    public void wash() {

    }

    @Override
    public void cooking() {
        System.out.println("大廚作飯");
    }
}
複製代碼

咱們再寫一下小廚的部分，小廚也是實現廚師接口。

小廚不作飯，小廚只洗菜。

package com.fanqiekt.principle.segregation;

/**
 * 小廚
 *
 * @author 番茄課堂-懶人
 */
public class Kitchen implements IChef {
    @Override
    public void wash() {
        System.out.println("小廚洗菜");
    }

    /**
     * 作飯的邏輯與小廚無關
     */
    @Override
    public void cooking() {

    }
}
複製代碼

這樣的寫法，好很差？

固然很差，每一個類都冗餘了與他不相關的方法。例如，BigChef中的wash方法、Kitchen中的cooking方法。

這種現象是怎麼致使的呢？

接口不夠最小化。接口隔離原則就是爲了解決這種問題的。

咱們能夠寫成兩個接口，一個是作飯的接口，一個是洗菜的接口。

package com.fanqiekt.principle.segregation;

/**
 * 作飯接口
 *
 * @author 番茄課堂-懶人
 */
public interface ICook {

    /**
     * 作飯
     */
    void cooking();
}

複製代碼

作飯的接口。

package com.fanqiekt.principle.segregation;

/**
 * 洗菜接口
 *
 * @author 番茄課堂-懶人
 */
public interface IWash {

    /**
     * 洗菜
     */
    void wash();

}
複製代碼

洗菜的接口。

咱們再來看一下符合接口隔離原則的具體實現類。

package com.fanqiekt.principle.segregation;

/**
 * 大廚
 *
 * @author 番茄課堂-懶人
 */
public class BigChef implements ICook{

    /**
     * 大廚只負責作飯，只處理和作飯相關的邏輯
     */
    @Override
    public void cooking() {
        System.out.println("大廚作飯");
    }
}
複製代碼

這樣就沒有冗餘代碼了。

package com.fanqiekt.principle.segregation;

/**
 * 小廚
 *
 * @author 番茄課堂-懶人
 */
public class Kitchen implements IWash {

    /**
     * 小廚只負責洗菜，只處理和洗菜相關的邏輯
     */
    @Override
    public void wash() {
        System.out.println("小廚洗菜");
    }
}
複製代碼

小廚一樣也沒有冗餘代碼了。

這樣的寫法是否是更加的優雅了。

若是新增一種既洗菜又作飯的廚師類型，那同時實現ICook與IWash接口就能夠了。

三、優勢

它與單一職責原則相似，優勢也是相似的。

下降風險 修改其中的一個業務，不會影響到業務。

易維護易擴展 沒有冗餘代碼，符合接口隔離原則的接口，會更加容易擴展以及維護。

四、嘻哈說

接下來，請您欣賞接口隔離原則的原創歌曲。

嘻哈說：接口隔離原則
做曲：懶人
做詞：懶人
Rapper:懶人

奮鬥了多年總算熬成了大廚纔不要關心洗菜
這些雜事都摘不掉
剛入行一兩年但兢兢業業的小廚還不到烹飪大菜
由於這些來不了
因此接口功能太多在胡鬧
接口功能應該儘量最少
這就是接口隔離
核心思想就是接口最小
這樣才結構得體
風險下降易擴展維護也有格局
用起來它是絕對合理
複製代碼

試聽請點擊這裏

閒來無事聽聽曲，知識已填腦中去；

學習複習新方式，頭戴耳機不小覷。

番茄課堂，學習也要酷。