接口隔離原則（Interface Segregation Principle, ISP）是指用多個專門的接口，而不使用單一的總接口，客戶端不應該依賴它不需要的接口。這個原則指導我們在設計接口時應當注意以下幾點：
（1）一個類對另一個類的依賴應該建立在最小的接口之上。
（2）建立單一接口，不要建立龐大臃腫的接口。
（3）盡量細化接口，接口中的方法盡量少（不是越少越好，一定要適度）。
接口隔離原則符合我們常說的高內聚、低耦合的設計思想，可以使類具有很好的可讀性、可擴展性和可維護性。我們在設計接口的時候，要多花時間去思考，要考慮業務模型，包括對以后有可能發生變更的地方還要做一些預判。所以，對於抽象、對於業務模型的理解是非常重要的。下面我們來看一段代碼，對一個動物行為進行抽象描述。
IAnimal接口的代碼如下：
public interface IAnimal {
void eat();
void fly();
void swim();
}
Bird類的代碼如下：
public class Bird implements IAnimal {
@Override
public void eat() {}
@Override
public void fly() {}
@Override
public void swim() {}
}
Dog類的代碼如下：
public class Dog implements IAnimal {
@Override
public void eat() {}
@Override
public void fly() {}
@Override
public void swim() {}
}
可以看出，Bird的swim()方法可能只能空着，但Dog的fly()方法顯然是不可能的。這時候，我們針對不同動物行為來設計不同的接口，分別設計IEatAnimal、IFlyAnimal和ISwimAnimal接口，來看代碼。
IEatAnimal接口的代碼如下：
public interface IEatAnimal {
void eat();
}
IFlyAnimal接口的代碼如下：
public interface IFlyAnimal {
void fly();
}
ISwimAnimal接口的代碼如下：
public interface ISwimAnimal {
void swim();
}
Dog只實現IEatAnimal和ISwimAnimal接口，代碼如下：
public class Dog implements ISwimAnimal,IEatAnimal {
@Override
public void eat() {}
@Override
public void swim() {}
}
來看一下兩種類圖的對比，如下圖所示，還是非常清晰明了的。
關注微信公眾號『 Tom彈架構 』回復“設計模式”可獲取完整源碼。
本文為“Tom彈架構”原創，轉載請注明出處。技術在於分享，我分享我快樂！
如果本文對您有幫助，歡迎關注和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力。關注微信公眾號『 Tom彈架構 』可獲取更多技術干貨！
其他設計原則
Tom彈架構：開閉原則（Open-Closed Principle，OCP）
Tom彈架構：依賴倒置原則（Dependence Inversion Principle，DIP）
Tom彈架構：單一職責原則（Simple Responsibility Pinciple，SRP）
Tom彈架構：迪米特原則（Law of Demeter LoD）