设计模式六大原则（5）：接口隔离原则

定义：客户端不应该依赖它不需要的接口。另外一种定义：类间的依赖关系应该建立在最小的接口上。

场景：在接口I中定义多个方法（假如A，B，C，D），类C1通过实现接口I来扩展自己需要的方法A、B；类C2通过实现接口I来扩展自己需要的方法C、D；那么接口I对于类C1和类C2来说不是最小接口，则类C1和类C2必须去实现他们不需要的方法。

解决方案：采用接口隔离原则。将臃肿的接口I拆分为独立的几个接口，类C1和类C2分别与他们需要的接口建立依赖关系。

接口隔离原则说白了就是，让客户端依赖的接口尽可能地小，接口隔离原则将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是解耦，从而容易重构。

根据上面的场景，用代码来讲解接口隔离原则的使用。假如有这么一个需求，老师有两个职责，备课和讲课；学生也有两个职责，听课和复习。如果不考虑接口隔离原则，可以这样来实现：

先定义一个接口，用来定义所有的职责：

**
 * Created by LJW on 2018/8/27.
 * 定义接口
 */
public interface ILearning {

    //备课
    String prepareLessons();

    //讲课
    String teach();

    //听课
    String study();

    //复习
    String review();
}

定义一个教师类，实现上面的接口：

/**
 * Created by LJW on 2018/8/27.
 * 老师类
 */
public class Teacher implements ILearning {

    @Override
    public String prepareLessons() {
        return "老师正在备课.......";
    }

    @Override
    public String teach() {
        return "老师正在讲课.......";
    }

    @Override
    public String study() {
        return null;
    }

    @Override
    public String review() {
        return null;
    }
}

定义一个学生类，实现上面的接口：

/**
 * Created by LJW on 2018/8/27.
 * 学生类
 */
public class Students implements ILearning {

    @Override
    public String prepareLessons() {
        return null;
    }

    @Override
    public String teach() {
        return null;
    }

    @Override
    public String study() {
        return "学生正在听课......";
    }

    @Override
    public String review() {
        return "学生正在复习......";
    }
}

运行结果：

老师正在备课.......

老师正在讲课.......

学生正在听课......

学生正在复习......

从结果来看，是没有问题的，但这时老师有意见了：我备好课、讲完课就完事了，你怎么还给我戴两个听课、复习的空帽子？？？学生也开始喃喃自语了：谁去鸟你备课、讲课！！！

之所以出现这种问题，分析上面的代码，是因为接口定义的太大，不满足客户端依赖的接口尽可能地小这一原则，导致了代码的臃肿。这时我们可以遵循接口隔离原则对上面的代码进行重构，将上面的接口拆分成为更小的和更具体的接口，这样老师和学生只需要知道他们感兴趣的方法。

/**
 * Created by LJW on 2018/8/27.
 * 教师类接口
 */
public interface ITeacher {

    //备课
    String prepareLessons();

    //讲课
    String teach();
}

/**
 * Created by LJW on 2018/8/27.
 * 学生类接口
 */
public interface IStudents {

    //听课
    String study();

    //复习
    String review();
}

老师和学生分别实现自己感兴趣的接口：

/**
 * Created by LJW on 2018/8/27.
 * 老师类
 */
public class Teacher implements ITeacher {

    @Override
    public String prepareLessons() {
        return "老师正在备课.......";
    }

    @Override
    public String teach() {
        return "老师正在讲课.......";
    }

}


/**
 * Created by LJW on 2018/8/27.
 * 学生类
 */
public class Students implements IStudents {

    @Override
    public String study() {
        return "学生正在听课......";
    }

    @Override
    public String review() {
        return "学生正在复习......";
    }
}

通过对接口这么一分解，老师和学生便可各司其职，愉快的工作了。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。但是，采用接口隔离原则对接口进行约束时要注意，接口尽量小，但要把握好限度。对接口进行细化可以减少代码的臃肿，提供程序的灵活性是不争事实，但是如果接口过小，则会造成接口数量过多，使程序难以维护，反而适得其反。所以一定要适可而止。