接口隔离原则，简单的说就是把接口最小粒度化,从而减少代码的后期的维护成本。增加代码的可维护性以及可读性等
举个例子：
我们定义一个人的行为接口。
/**
* @author freebird
* @date 2020/4/24 21:56
*/
public interface Human {
void eat();
void walk();
void sleep();
}
它具有吃睡走路的能力。
给它一个默认实现类
/**
* @author freebird
* @date 2020/4/24 21:58
*/
public class SimpleMan implements Human {
@Override
public void eat() {
System.out.println("我吃粑粑...");
}
@Override
public void walk() {
System.out.println("我走不动...");
}
@Override
public void sleep() {
System.out.println("我只想睡觉，不想加班...");
}
}
看着没什么毛病。但是假如有个坐轮椅的残疾人呢？他不具备走路的能力是吧，所以这个接口设计的太大了。所以我们应该把它细粒度化，根据行为来拆分。
public interface Walkable { void walk(); } public interface Sleepable { void sleep(); } public interface Eatable { void eat(); }
这样的设计接口抽象程度显然更高了，可以是人去实现，也可以是具备这些能力的动物或者植物都可以实现。
public class DisabledMan implements Eatable,Sleepable { @Override public void eat() { System.out.println("我能吃莽莽"); } @Override public void sleep() { System.out.println("我能睡觉觉"); } }
这样坐轮椅的残疾人就无需去实现走路这个行为的接口，更加语义化，更加符合面向对象的设计
如果我们不这样去把行为接口抽象出来，我们当然也可以在实现中进行判断，但是很显然这不符合具体的抽象了。
因此，接口隔离是很有必要的，在实际的业务开发中，可能很难考虑到。但是闲来没事试着去重构一下系统也许有惊喜。
原文：https://www.cnblogs.com/neverendingDreaming/p/12770545.html