设计模式六大原则： 辅导班的因材施教 -- 接口隔离原则

我的女朋友小肉是一名光荣的辅导班老师，说来惭愧，我上初中那会儿最讨厌辅导班老师了，每天上学都这么累了，晚上还得去见辅导班老师，神烦，奈何目前的教育机制下，很多家长认为辅导班是提高成绩比较靠谱的方式，导致这个行业市场很大。

小肉教三个水平不同的小班，那天看她在准备讲义和试题，同一章内容需要做三份，其中很多内容都是重复的，自诩设计模式略懂一二的我跟她说：

你这个讲义跟我敲代码很像，相似的内容这么多，直接复制粘贴容易出问题啊，还不如把公共的部分提一个接口，然后让三种水平的讲义都实现这个接口

比如这样：

教案接口，指定所有班级要做的事：

/**
 * 教案接口，指定共同内容
 */
public interface TeachingPlanImpl {
    /**
     * 教授基础知识
     */
    void teachBaseKnowledge();

    /**
     * 教授拓展知识
     */
    void teachExtraKnowledge();

    /**
     * 教授拔高知识
     */
    void teachComplexKnowledge();

    /**
     * 布置简单作业
     */
    void assignBaseHomeWork();

    /**
     * 布置提升作业
     */
    void assignExtraHomeWork();

    /**
     * 布置复杂作业
     */
    void assignComplexHomeWork();
}

然后让三个班级的讲义实现这个接口：

/**
 * 基础班教案
 * Created by zhangshixin on 8/15/2016.
 */
public class TeachPlanBase implements TeachingPlanImpl {
    @Override
    public void teachBaseKnowledge() {

    }

    @Override
    public void teachExtraKnowledge() {

    }

    @Override
    public void teachComplexKnowledge() {

    }

    @Override
    public void assignBaseHomeWork() {

    }

    @Override
    public void assignExtraHomeWork() {

    }

    @Override
    public void assignComplexHomeWork() {

    }
}

//其余两个拔高班 TeachPlanExtra 、奥数班 TeachPlanComplex 教案类似，不再列举

这样你有需要改动的时候修改一处就好了，多省劲啊哈哈（得意脸）

没想到肉肉说：

可是普通班的孩子只要掌握基础就好了啊，他们要是发现自己不会的那么多该多难受 T.T 。基础班的只要基础知识和题，拓展班也不需要做奥数啊。而且哦，万一我的模板教案打错了，一下次还影响了三个班级的孩子。

没有好处反而有可能带来坏处，我觉得你设计的不好！

.

你！！ 好吧，我竟无言以对

抽象、封装，不是要把公共的都提出去吗？带着疑问我开始求医问药，直到发现了：

接口隔离原则 ISP (Interface Segregation Principle)

定义：

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。

接口存在就是为了把细节和抽象分离开来，但是如果一个接口抽象的内容太多，其实就等于没有抽象。一个过于臃肿的接口会给它的实现类带来很多压力，比如上述例子讲的教案问题，对胖接口的修改会影响到很多实现类，有时候可能会带来大麻烦。

正确的方法是将胖接口分割成几个小接口，因材施教，不要给客户端暴露不需要的接口。

这里比较纠结的是接口究竟怎么算大，怎么算小，接口隔离原则也没有告诉我们，我们需要注意的就是接口的实现类尽量少实现不需要的方法，至于那个度还需要自己把握。

总结：一个诸葛亮不如 N 个裨将，万一诸葛亮病了呢

还容易混淆的是 单一职责原则和接口隔离原则的区别？

• 接口隔离原则强调的是设计时的架构分离，把不同功能分给不同的接口，让实现类避免少了解与己无关的方法、通过实现不同接口保证与外部的耦合；
• 单一职责原则强调的是 实现时的职责分离，具体功能下的不同实现要封装在不同的模块，尽量避免牵一发而动全身。

感谢：

http://my.oschina.net/heweipo/blog/422796
http://blog.csdn.net/zhengzhb/article/details/7296921