接口隔离原则（Interface Segregation Principle， ISP）
定义：
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小接口上。
问题由来：
类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：
将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
实践：
举个Phone的例子，首先定义一个接口，声明可以打电话和上网。
public interface Phone {
void call();
void net();
}
//有一个iPhone手机去实现这个接口
public class iPhone implements Phone {
@Override
public void call() {
System.out.println("我能打电话");
}
@Override
public void net() {
System.out.println("我能上网");
}
}
但是现在有个iPod也能上网，但是不能打电话，那么实现Phone接口的时候就需要call()为空，这就是接口不分明的情况，修改方法也就显然易见了。
public interface ICall {
void call();
}
public interface INet {
void net();
}
//iphone手机
public class iphone implements ICall,INet {
@Override
public void call() {
System.out.println("我能打电话");
}
@Override
public void net() {
System.out.println("我能上网");
}
//ipod
public class ipod implements INet {
@Override
public void net() {
System.out.println("我能上网");
}
}
}
以上把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则，这里只是举个例子说明什么是接口隔离，但是并不是说每一个方法都单独一个接口，设计师有限度的。
总结
接口要尽量小。
这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。
根据接口隔离原则拆分接口时，首先必须满足单一职责原则。接口要高内聚。
高内聚就是要提高接口、类、模块的处理能力，减少对外的交互。
具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺地越少对系统开发越有利，变更的风险也就越少，同时也有利于降低成本。定制服务。
定制服务就是单独为一个个体提供优良的服务。接口设计是有限度的。
接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个度只能根据经验和常识判断，没有一个固化或可测量的标准。
实践中尽量应遵循的规则
● 一个接口只服务于一个子模块或业务逻辑；
● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口只拥有需要的方法；
● 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；
● 了解环境，拒绝盲从。设计符合自己工作业务逻辑的接口。
