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

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

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

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

比如这样:

教案接口,指定所有班级要做的事:

/**
 * 教案接口,指定共同内容
 */
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

时间: 2024-08-10 23:17:12

设计模式六大原则: 辅导班的因材施教 -- 接口隔离原则的相关文章

设计模式六大原则(4)--接口隔离原则

定义: 客户端不应该依赖它不需要的接口:类之间的依赖关系应建立在最小的接口之上.接口隔离原则英文全称为Interface Segregation Principle ,简称为ISP. 个人理解: 通俗的来说,接口不能臃肿庞大,而使根据具体需要尽量的细化.接口中的方法也要尽可能的少.接口是设计对外的一种契约,通过分散定义多个接口可以预防将来变更的扩散,使得真个系统变得更加稳定和更具有可维护性. 问题由来: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类C不是最小的接口,那么

设计模式六大原则(4)——接口隔离原则

定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接

设计模式 之 设计的 六大原则(4) 接口隔离原则

接口隔离原则 定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1 未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现

设计模式原则(3)接口隔离原则(ISP)

接口隔离原则的英文翻译是“ Interface Segregation Principle”,缩写为 ISP. Robert Martin 在 SOLID 原则中是这样定义它的: “Clients should not be forced to depend upon interfaces that they do not use.” 直译成中文的话就是:客户端不应该强迫依赖它不需要的接口.其中的“客户端”,可以理解为接口的调用者或者使用者. 实际上,“接口”这个名词可以用在很多场合中.生活中我

设计模式六大原则(4):接口隔离原则(Interface Segregation Principle)

接口隔离原则: 使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变. 定义:

设计模式六大原则(4):接口隔离原则(转载)

设计模式六大原则(4):接口隔离原则 定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法

【转】设计模式六大原则(4):接口隔离原则

定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类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是

设计模式六大原则之四:接口隔离原则

定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接

[转]设计模式六大原则[4]:接口隔离原则

定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接