简单理解遵循接口隔离原则的Java设计模式编程_java

定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
问题由来:类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是对类C依赖的实现。对于类B和类D来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口I,所以也必须要实现这些用不到的方法。

我们首先先看一个违反接口隔离的例子:

public interface IWorker {
  public void work();
  public void eat();
} 

public class Worker implements IWorker{
  @Override
  public void work() {
    // TODO 工人工作
  } 

  @Override
  public void eat() {
    // TODO 工人吃饭
  }
} 

public class Robot implements IWorker {
  @Override
  public void work() {
    // TODO 机器人工作
  } 

  @Override
  public void eat() {
    // TODO 机器人吃饭?
  }
} 

由于机器人是不需要吃饭的,所以IWorker被认为是一个臃肿的接口,当然你也可以在Robot类中的eat方法做空实现,但是这样可能会产生不可预计的BUG,比如eat方法需要消耗盒饭数量的话,就会出现不对应的现象。
下面是修改后的实现:

public interface IWorker {
  public void work();
} 

public interface IDiet {
  public void eat();
} 

public class Worker implements IWorker, IDiet{
  @Override
  public void work() {
    // TODO 工人工作
  } 

  @Override
  public void eat() {
    // TODO 工人吃饭
  }
} 

public class Robot implements IWorker {
  @Override
  public void work() {
    // TODO 机器人工作
  }
} 

总结:
1. 接口要尽量小,并高内聚,不过要适当,太细化不好维护。
2. 如果已经设计成了臃肿的接口,可以使用适配器模式隔离它。

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索java
, 设计模式
接口隔离原则
隔离的实施应遵循、本我遵循什么原则、遵循从强原则的不包括、解释问题遵循的原则是、削弱问题遵循的原则是,以便于您获取更多的相关知识。

时间: 2024-09-01 03:32:08

简单理解遵循接口隔离原则的Java设计模式编程_java的相关文章

java 接口隔离原则问题?

问题描述 为什么要遵循接口隔离原则?书上说容易扩展,从什么角度能看出来容易扩展呢?请大家指点下.java 新手, 我已经写过写过学校项目了. 问题补充:嗯 这个是一方面.更主要的为什么说成容易扩展.在日常的项目中,如果把Service层的接口合并成一个会怎么样呢?出了名字不好找,还有实现类实现很多无用的方法. 解决方案 我觉得最大的问题在于耦合,如果使用大接口,与这个接口耦合的类自然就多.如果这个接口做了修改,会影响到很多类.这样代码修改量就大,而且加大了测试的量.解决方案二:最重要的是这样的设

举例说明Java设计模式编程中ISP接口隔离原则的使用_java

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

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

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

深入理解JavaScript系列(21):S.O.L.I.D五大原则之接口隔离原则ISP详解

 这篇文章主要介绍了深入理解JavaScript系列(21):S.O.L.I.D五大原则之接口隔离原则ISP详解,本文讲解了JavaScript接口.ISP与JavaScript.堕落的实现.静态耦合.语义耦合.可扩展性等内容,需要的朋友可以参考下     前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第4篇,接口隔离原则ISP(The Interface Segregation Principle). 英文原文:http://freshbrewedcode.c

设计模式学习:接口隔离原则

对接口的理解 这里的接口,不是java语言内部的interface的意思,在这里,可以将接口理解为一个类提供的所有的方法的特征集合,通俗点说就是所有可见方法和可见变量(java的说法, c++的说法是可见函数和可见属性元素). 接口隔离原则的定义: 一个类对于另一个类的依赖应当建立在最小的接口上,不应当依赖一些不需要的接口. 从实例中来体会定义.假设我们有两个学生类,文科生和理科生,他们需要考试,我们把考试抽象出一个接口,让不同的实现类来实现.如下图一所示: 图一 从上面的设计中,我们用代码实现

《Android 源码设计模式解析与实战》——第1章,第1.5节系统有更高的灵活性——接口隔离原则

1.5 系统有更高的灵活性--接口隔离原则 接口隔离原则英文全称是InterfaceSegregation Principles,缩写是ISP.ISP的定义是:客户端不应该依赖它不需要的接口.另一种定义是:类间的依赖关系应该建立在最小的接口上.接口隔离原则将非常庞大.臃肿的接口拆分成更小的和更具体的接口,这样客户将会只需要知道他们感兴趣的方法.接口隔离原则的目的是系统解开耦合,从而容易重构.更改和重新部署. 接口隔离原则说白了就是,让客户端依赖的接口尽可能地小,这样说可能还是有点抽象,我们还是以

设计模式之禅之六大设计原则-接口隔离原则

接口隔离原则一:什么是接口?● 实例接口(Object Interface)        ---->Person zhangSan=new Person()产生了一个实例,这个实例要遵从的标准就是Person这个类,Person类就是zhangSan的接口● 类接口(Class Interface)        ---->Java中经常使用的interface关键字定义的接口. 二:那什么是隔离呢?它有两种定义:      ---->事物的定义一般都比较难理解,晦涩难懂是正常的.我们

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

ISP(Interface Segregation Principle),接口隔离原则   它要求如下: ①  一个类对另一个类的依赖性要建立在最小接口上. ②  使用多个专门的接口比使用单一的总接口要好. ③  没有关系的接口不可合并成一个臃肿的大接口. ④  对于臃肿的大接口应分成几个合适的小接口.   接口分离方法: 1.使用委托分离接口:把请求委托给别的接口的实现类来完成需要的职责. 2.使用多重继承分离接口:通过实现多个接口来完成需要的职责.   总结: 大接口导致客户程序之间产生不必

理解Java设计模式编程中的迪米特原则_java

定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合.          自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的.          迪米特法则又叫最少知道原则,最早是在1987年