定义
客户端不应该被强迫依赖它不需要的接口。
其中的“客户端”,可以理解为接口的调用者或者使用者。
方式
在 badexample 中,鸟依赖了会游泳的接口,狗依赖了飞的接口(不合理)。故,对 IAnimal
接口进行细粒度的拆分,在 goodexample 中,将其分成了 IEat
、IFly
、ISwim
三个接口,调用方(鸟、狗)可以按需实现自己能用的接口,更加合理。
思考
思考一:接口隔离原则和单一职责原则一样吗?
不太一样。单一职责针对的是模块、类、接口的设计,而接口隔离更针对于接口。此外,单一职责更强调自己的特征和功能是否高度内聚,而接口隔离强调的是针对同一调用方的高内聚不同调用方的低耦合(接口可以理解为方法的集合)
代码
坏设计
你见过会飞的狗吗?
/**
* 动物接口
*
* @author mindartisan.blog.csdn.net
* @date
*/
public interface IAnimal {
/**
* 吃
*/
void eat();
/**
* 飞
*/
void fly();
/**
* 游泳
*/
void swim();
}
/**
* 狗
*
* @author mindartisan.blog.csdn.net
* @date
*/
public class Dog implements IAnimal{
@Override
public void eat() {
}
@Override
public void fly() {
}
@Override
public void swim() {
}
}
public class Bird implements IAnimal{
@Override
public void eat() {
}
@Override
public void fly() {
}
@Override
public void swim() {
}
}
好设计
/**
* 吃接口
*
* @author mindartisan.blog.csdn.net
* @date
*/
public interface IEat {
/**
* 吃
*/
void eat();
}
/**
* 飞接口
*
* @author mindartisan.blog.csdn.net
* @date
*/
public interface IFly {
/**
* 飞
*/
void fly();
}
/**
* 游泳接口
*
* @author mindartisan.blog.csdn.net
* @date
*/
public interface ISwim {
/**
* 游泳
*/
void swim();
}
/**
* 鸟
*
* @author mindartisan.blog.csdn.net
* @date
*/
public class Bird implements IFly,IEat{
@Override
public void eat() {
}
@Override
public void fly() {
}
}
/**
* 狗
*
* @author mindartisan.blog.csdn.net
* @date
*/
public class Dog implements IEat,ISwim{
@Override
public void eat() {
}
@Override
public void swim() {
}
}