1.定义
1.客户端不应该被迫或强制依赖它不需要的接口
2.接口不应太臃肿要小
2.作用
- 业务逻辑更清晰
- 系统更灵活
3.案例
以唱歌为例子，下面是歌曲接口，提供英文歌和中文歌两个方法
//歌曲
public interface ISong {
//英文歌
void foreignMusic();
//中文歌
void chineseMusic();
}
人实现ISong接口唱歌
/**
* 人
*/
public class Person implements ISong {
@Override
public void foreignMusic() {
System.out.print("英文歌");
}
@Override
public void chineseMusic() {
System.out.print("中文歌");
}
}
唱歌例子实现完毕！没有问题。
但是如果这个时候出现一个外国人他同样要唱歌，但是他又不需要唱中文歌，如果保持现在的设计，实现ISong接口，这将被迫依赖他他不需要的接口，说明ISong接口的设计是有缺陷的。我们可以重新将ISong接口分为两个一个提供中文歌，一个提供外国歌，修改如下
/**
* 中文歌曲
*/
public interface IChineseSong {
//中文歌
void chineseMusic();
}
/**
* 外国歌曲
*/
public interface IForeignSong {
//外国歌
void foreignMusic();
}
外国人要唱歌只需要实现IForeignSong这一个接口，Person改为实现两个接口，成功解决了外国人不需要唱中文歌的问题，即使之后有新的歌加入也不怕
/**
* 外国人
*/
public class Foreigner implements IForeignSong {
@Override
public void foreignMusic() {
System.out.print("英文歌");
}
}
/**
* 人
*/
public class Person implements IChineseSong, IForeignSong {
@Override
public void foreignMusic() {
System.out.print("英文歌");
}
@Override
public void chineseMusic() {
System.out.print("中文歌");
}
}
再说一下单一职责和接口隔离的区别， 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离单一职责原则，它针对的是程序中的实现和细节，而接口隔离原则主要约束的是接口，主要针对的是抽象，对程序整体框架的构建。
4.总结
接口的设计粒度应该尽量小，但是也要适度，根据实际情况划分接口粒度。使各个模块独立存在，模块与模块之间的接口应少而简单。
