接口隔离原则：通过设计规避变更风险

接口隔离原则是什么

接口隔离原则：客户端不应该依赖于它不需要的接口，而是将类间的依赖关系建立在最小的接口上。

换句话说，在实际的开发中，客户端需要什么接口我们就为它提供什么接口，并把它不需要的接口剔除掉。这么一来就会有一个问题：有些接口涵盖的功能比较多，我们类在实现接口的时候可能只需要应用到接口中的某些方法，那怎么办呢？我们应该把类的接口尽可能地细化，需要什么就用什么，而不是一味地贪“多”。

为什么需要依赖倒置原则

还是用打游戏来做例子吧：

一款游戏具有很多很多的元素，有的 UI 特别好看，有的动作特别酷，有点故事特别有趣，等等……

public interface IGame {
    public void niceUI();

    public void goodStory();

    public void coolAction();

    public void newPlayMode();

    //还有很多很多
}

不同的游戏包含的游戏元素是不一样的，不同的游戏的特点也不一样，例如：

动作类游戏：

public class ActionGame implements IGame {

    @Override
    public void niceUI() {
        System.out.println("UI华丽");
    }

    @Override
    public void goodStory() {
        System.out.println("故事一般");
    }

    @Override
    public void coolAction() {
        System.out.println("动作酷炫");
    }

    @Override
    public void newPlayMode() {
        System.out.println("游戏模式一般");
    }
}

故事类游戏：

public class StoryGame implements IGame{

    @Override
    public void niceUI() {
        System.out.println("UI小清新");
    }

    @Override
    public void goodStory() {
        System.out.println("故事有趣");
    }

    @Override
    public void coolAction() {
        System.out.println("动作一般");
    }

    @Override
    public void newPlayMode() {
        System.out.println("游戏模式新");
    }
}

乍一看这样没什么问题，不妨想一想，有的游戏爱好者觉得动作类游戏还需要考虑游戏自由度，那我们为了满足这个需求，就得在 IGame 接口中添加方法。添加了方法之后，StoryGame 类也要因此发生改变，然而 StoryGame 根本不需要考虑游戏的自由度问题啊，为什么要影响 StoryGame 类？同样的道理，如果游戏爱好者们说故事类游戏需要考虑人物动作和场景是否细腻、真实，而这个在动作类里不需要考虑时，我们为什么要去改变 ActionGame 类呢？所以我们会发现，IGame 接口实在“太大了”，我们需要将它细化：

public interface IUI {
    public void niceUI();
}

public interface IAction {
    public void coolAction();
}

public interface IStory {
    public void goodStory();
}

public interface IPlayMode {
    public void newPlayMode();
}

通过这样细分接口，让我们的游戏类需要什么接口就实现什么接口，在需要修改时也只修改特定的接口，保持了接口的稳定，提高系统的灵活性和可维护性。

保证接口的纯洁性

• 接口要尽可能小
• 接口要高内聚
• 定制服务
• 接口设计是有限度的

实际运用

• 一个接口只服务于一个子模块或业务逻辑
• 通过业务逻辑压缩接口中的 public 方法
• 已经被污染了的接口尽量去修改，若变更的风险较大，则采用适配器模式去转化处理
• 了解环境，拒绝盲从他人的设计