简单理解遵循接口隔离原则的Java设计模式编程

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
问题由来：类a通过接口i依赖类b，类c通过接口i依赖类d，如果接口i对于类a和类b来说不是最小接口，则类b和类d必须去实现他们不需要的方法。
解决方案：将臃肿的接口i拆分为独立的几个接口，类a和类c分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
举例来说明接口隔离原则：

 这个图的意思是：类a依赖接口i中的方法1、方法2、方法3，类b是对类a依赖的实现。类c依赖接口i中的方法1、方法4、方法5，类d是对类c依赖的实现。对于类b和类d来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口i，所以也必须要实现这些用不到的方法。

我们首先先看一个违反接口隔离的例子：

public interface iworker { 
  public void work(); 
  public void eat(); 
} 
 
public class worker implements iworker{ 
  @override 
  public void work() { 
    // todo 工人工作   
  } 
 
  @override 
  public void eat() { 
    // todo 工人吃饭 
  } 
} 
 
public class robot implements iworker { 
  @override 
  public void work() { 
    // todo 机器人工作     
  } 
 
  @override 
  public void eat() { 
    // todo 机器人吃饭？  
  } 
} 

由于机器人是不需要吃饭的，所以iworker被认为是一个臃肿的接口，当然你也可以在robot类中的eat方法做空实现，但是这样可能会产生不可预计的bug，比如eat方法需要消耗盒饭数量的话，就会出现不对应的现象。
下面是修改后的实现：

public interface iworker { 
  public void work(); 
} 
 
public interface idiet { 
  public void eat(); 
} 
 
public class worker implements iworker, idiet{ 
  @override 
  public void work() { 
    // todo 工人工作   
  } 
 
  @override 
  public void eat() { 
    // todo 工人吃饭 
  } 
} 
 
public class robot implements iworker { 
  @override 
  public void work() { 
    // todo 机器人工作     
  } 
} 

总结：
1. 接口要尽量小，并高内聚，不过要适当，太细化不好维护。
2. 如果已经设计成了臃肿的接口，可以使用适配器模式隔离它。