软件架构设计原则之接口隔离原则

接口隔离原则（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弹架构：30个设计模式真实案例，挑战年薪60W不是梦本文节选自《设计模式就该这样学》本文自2012年10月29日起持续连载，请大家持续关注....序言Design Patterns: Elements of Reusable Object-Oriented Software（以下简称《设计模式》），一书由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著（Addison-Wesley，1995）。这四位作者常被称为“四人组（Gang of Four）”，而这本书也就被称为“四人组（或 .https://blog.csdn.net/gupaoedu_tom/article/details/121042618

 其他设计原则

Tom弹架构：开闭原则（Open-Closed Principle，OCP）https://blog.csdn.net/gupaoedu_tom/article/details/120895316

Tom弹架构：依赖倒置原则（Dependence Inversion Principle，DIP）https://blog.csdn.net/gupaoedu_tom/article/details/120905135

Tom弹架构：单一职责（Simple Responsibility Pinciple，SRP）https://blog.csdn.net/gupaoedu_tom/article/details/120906842

Tom弹架构：迪米特原则（Law of Demeter LoD）https://blog.csdn.net/gupaoedu_tom/article/details/120907187

Tom弹架构：里氏替换原则（Liskov Substitution Principle，LSP）https://blog.csdn.net/gupaoedu_tom/article/details/120907389

Tom弹架构：合成复用原则（Composite/Aggregate Reuse Principle，CARP）https://blog.csdn.net/gupaoedu_tom/article/details/120907563