面向对象六大原则——接口隔离原则

什么是接口隔离原则(Interface Segregation Principle, ISP)

 接口对于Java开发者来说都不陌生，它几乎存在于每一个Java程序中，是抽象的代名词。在讲接口隔离原则之前，先说说接口，接口分为以下两种：

• 实例接口(Object Interface)： 在Java中声明一个类，然后用new关键字产生一个实例，是对一个类型的事物的描述，这就是一种接口。或许我们乍一看会有点懵，怎么和我们原来学习的接口不一样呢，其实我们这样想，我们都知道，在Java中有一个Class类，表示正在运行的类和接口，换句话说每一个正在运行时的类或接口都是Class类的对象，这是一种向上的抽象。接口是一种更为抽象的定义，类是一类相同事物的描述集合，那为什么不可以抽象为一个接口呢？
• 类接口(Class Interface)： 这就是我们经常使用的用interface定义的接口

 这里插一句，接口隔离原则中所说的接口并不是狭意的在Java中用interface定义的接口，而是一种更为宽泛的概念，可以是接口，抽象类或者实体类。

 接口隔离原则定义如下：

• 客户端不应该依赖它不需要的接口
• 类间的依赖关系应该建立在最小的接口上

 其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿不堪。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加轻便灵活。或许看到接口隔离原则这样的定义很多人会觉得和单一职责原则很像，但是这两个原则还是有着很鲜明的区别。接口隔离原则和单一职责原则的审视角度是不同的，单一职责原则要求类和接口职责单一，注重的是职责，是业务逻辑上的划分，而接口隔离原则要求方法要尽可能的少，是在接口设计上的考虑。例如一个接口的职责包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，并规定了“不使用的方法不能访问”，这样的设计是不符合接口隔离原则的，接口隔离原则要求“尽量使用多个专门的接口”，这里专门的接口就是指提供给每个模块的都应该是单一接口(即每一个模块对应一个接口)，而不是建立一个庞大臃肿的接口来容纳所有的客户端访问。

接口隔离原则的使用

 在说接口隔离原则之前，我们先说一个没有使用该原则的例子，然后通过前后对比，来看看有什么不同之处。大家一听到“美女”这个字眼，会想到什么呢？别激动啊，我没啥意思，只是想给美女来定一个通用的标准：面貌，身材与气质，一般来说，长得好看的，身材不错的，气质出众的都可以称为美女。假如我现在是一个星探，下面我要设计一个找美女的类图：

 定义了一个IPettyGirl接口，声明所有的美女都应该有goodLooking，niceFigure，greatTemperament。还定义了一个抽象类AbstractSearcher，其作用就是搜索美女并显示其信息。下面是接口的定义与实现：

//美女接口
public interface IPettyGirl {
    //要有姣好的面孔
    public void goodLooking();
    //要有好身材
    public void niceFigure();
    //要有气质
    public void greatTemperament();
}

//接口的实现类
public class PettyGirl implements IPettyGirl {
    private String name;

    public PettyGirl(String  name){
       this.name= name;
}

//脸蛋漂亮
public void goodLooking() {
     System.out.println(this.name + "---脸蛋很漂亮!");
}

//气质要好
public void greatTemperament() {
      System.out.println(this.name + "---气质非常好!");
}

//身材要好
public void niceFigure() {
      System.out.println(this.name + "---身材非常棒!");
   }
}

美女有了，就需要星探出马找美女了：

//星探的抽象
public abstract class AbstractSearcher {

    protected IPettyGirl pettyGirl;

    public AbstractSearcher(IPettyGirl pettyGirl){
        this.pettyGirl = pettyGirl;
   }
     //搜索美女， 列出美女信息
    public abstract void show();
}

//实现类
public class Searcher extends AbstractSearcher{

     public Searcher(IPettyGirl pettyGirl){
         super(pettyGirl);
   }

    //展示美女的信息
    public void show(){
        System.out.println("--------美女的信息如下： ---------------");
         //展示面容
        super.pettyGirl.goodLooking();
         //展示身材
        super.pettyGirl.niceFigure();
        //展示气质
        super.pettyGirl.greatTemperament();
      }
}

//下面是客户端代码
public class Client {
      //搜索并展示美女信息
      public static void main(String[] args) {
      //定义一个美女
      IPettyGirl xiaoMei = new PettyGirl("小美");
      AbstractSearcher searcher = new Searcher(yanYan);
      searcher.show();
    }
}

 OK，找美女的过程开发完毕，总体来说还是不错的，因为只要按照我们设计的原则来，那么找到的都是美女。但是这样的设计是最优的吗？现在考虑这样一种情况，由于人们审美的提高，或许颜值不一定是我们关注的主要因素，也许某个女生虽然颜值不是太高，但是气质很好，也可以把她称为美女。也有可能某些人喜欢身材匀称的，有的人觉得骨感一点好。也就是是说，美女的定义是可以宽泛话的，并非一成不变的。就如同我们的设计，必须符合我们定好的原则那才是美女，显然这是说不通的。所以上面的设计是有问题的，显然IPrettyGirl这个接口过于庞大了，根据接口隔离原则，星探AbstractSearcher应该依赖于具有部分特质的女孩子，但上面的设计却把这些特质都封装起来，放到一个接口中，这样就造成了封装过度，不容易扩展。

---

 现在我们找到了问题的原因，那就该接口隔离原则上场了。把原IPrettyGirl接口拆分为两个接口，一种是外形美女IGoodBodyGirl(相貌一流，身材不错，但气质可能差点)，另一种是气质美女IGreatTemperamentGirl(也许外形条件不出众，但是谈吐优雅得体，气质很好)。下面是设计类图：

public interface IGoodBodyGirl {
     //要有姣好的面孔
     public void goodLooking();
     //要有好身材
     public void niceFigure();
}

public interface IGreatTemperamentGirl {
    //要有气质
    public void greatTemperament();
}

public class PettyGirl implements IGoodBodyGirl,IGreatTemperamentGirl {
     private String name;

     public PettyGirl(String _name){
        this.name=_name;
  }

    //脸蛋漂亮
    public void goodLooking() {
        System.out.println(this.name + "---脸蛋很漂亮!");
   }

    //气质要好
    public void greatTemperament() {
       System.out.println(this.name + "---气质非常好!");
   }

   //身材要好
   public void niceFigure() {
        System.out.println(this.name + "---身材非常棒!");
   }
}

OK，现在经过重新设计，程序变得更加灵活，这就是接口隔离原则的强大之处。

ISP的几个使用原则

• 根据接口隔离原则拆分接口时，首先必须满足单一职责原则： 没有哪个设计可以十全十美的考虑到所有的设计原则，有些设计原则之间就可能出现冲突，就如同单一职责原则和接口隔离原则，一个考虑的是接口的职责的单一性，一个考虑的是方法设计的专业性(尽可能的少)，必然是会出现冲突。在出现冲突时，尽量以单一职责为主，当然这也要考虑具体的情况。
• 提高高内聚： 提高接口，类，模块的处理能力，减少对外的交互。比如你给杀手提交了一个订单，要求他在一周之内杀一个人，一周后杀手完成了任务，这种不讲条件完成任务的表现就是高内聚。具体来说就是：要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险就越小，也有利于降低成本。
• 定制服务： 单独为一个个体提供优良服务(只提供访问者需要的方法)。
• 接口设计要有限度： 根据经验判断

参考书籍

• 《设计模式之禅》