java 设计模式之依赖倒置实例详解

本文实例讲述了java 设计模式之依赖倒置。分享给大家供大家参考,具体如下:

依赖倒置的概念我也是在一篇博文上理解的,我觉得很精辟,所以收录在我的博客中。

类A 依赖 类B,之后根据需求 类A 变换为依赖 类C,这时候我们认为类A 是高层模块, 类B 和 类C 是低层模块。

什么是高层模块?什么是底层模块?
高层模块你可以理解为控制层,负责复杂的业务逻辑。
低层模块你可以理解为数据层,负责基本的原子操作。

什么意思? 我举个例子。
比如大胃王比赛。
在这场比赛中的规则是比赛谁吃馒头吃的最多。有参赛选手Q和W

/**
 * 馒头 实体类
 */
class SteamedBuns
{
  private String name = "馒头";
  public String getName()
  {
    return this.name;
  }
}
class Player
{
  //得了多少分
  private int intgral;
  private Sting name;
  public Player(String name)
  {
    setName(name);
  }
  public void setName(String name)
  {
    this.name = name;
  }
  public String getName()
  {
    return name;
  }
  public void setIntgral(int intgral)
  {
    this.intgral= intgral;
  }
  public int getIntgral()
  {
    return this.intgral;
  }
  public void eat(SteamedBuns steamedBuns)
  {
    System.out.println("我开吃了");
    setIntgral(getIntgral() + 1);
  }
}
public class Main
{
  pubic static void main(String[] agrs)
  {
    Player q = new Player("Q");//选手Q
    Player w = new Player("W");//选手W
    q.eat(new SteamedBuns());//选手Q吃馒头
    w.eat(new SteamedBuns());//选手W吃馒头
  }
}

那么,之后问题来了。Q和W 比分一样,胃口太大把馒头吃光了,现在好追加比赛吃包子。 但Q和W 的实体只支持吃馒头,这个不符合情理哇,不可能一个人能吃馒头不能吃包子哇。

public void eat(SteamedBuns steamedBuns)//选手只支持吃馒头

有的同学可能会想到用重载这个方法。

public void eat(SteamedBuns steamedBuns){}   //选手支持吃馒头
public void eat(SteamedStuffedBun steamedStuffedBun){} //选手支持吃包子

思路是正确的,但是在实际开发中,这样做,可能会给程序带来不必要的风险。
这时候依赖倒置的优越性就体现出来了。
还是思考。既然馒头吃光了,现在要比赛吃包子,那么我们想一下如果包子也吃光了还没有分出胜负,要继续追加比赛怎么办?再用重载吗? 人都是可以吃食物的,我们要让包子和馒头都实现食物接口。而参赛选手的依赖应该从包子和馒头 抽象出来 依赖食物接口。 这样只要一个类实现了食物接口,那么都能被吃。

/**
 * 食物接口
 */
interface Food
{
  public String getName();
}
/**
 * 馒头 实体类
 */
class SteamedBuns implements Food
{
  private String name = "馒头";
  @Override
  public String getName()
  {
    return this.name;
  }
}
/**
 * 包子 实体类
 */
class SteamedStuffedBun implements Food
{
  private String name = "包子";
  @Override
  public String getName()
  {
    return this.name;
  }
}
class Player
{
  private int intgral;
  private Sting name;
  public Player(String name)
  {
    setName(name);
  }
  public void setName(String name)
  {
    this.name = name;
  }
  public String getName()
  {
    return name;
  }
  public void setIntgral(int intgral)
  {
    this.intgral= intgral;
  }
  public int getIntgral()
  {
    return this.intgral;
  }
  /**取消对具体食物种类的依赖
  public void eat(SteamedBuns steamedBuns)
  {
    System.out.println("我开吃了");
    setIntgral(getIntgral() + 1);
  }
  */
  public void eat(Food food)
  {
    System.out.println("我开吃了");
    setIntgral(getIntgral() + 1);
  }
}
public class Main
{
  pubic static void main(String[] agrs)
  {
    Player q = new Player("Q");//选手Q
    Player w = new Player("W");//选手W
    q.eat(new SteamedBuns());//选手Q吃馒头
    w.eat(new SteamedBuns());//选手W吃馒头
    q.eat(new SteamedStuffedBun());//选手Q吃包子
    w.eat(new SteamedStuffedBun());//选手W吃包子
  }
}

这样的设计有助于降低类之间的耦合程度,抽象稳定的多,细节交给实现类。

更多java相关内容感兴趣的读者可查看本站专题:《Java面向对象程序设计入门与进阶教程》、《Java数据结构与算法教程》、《Java操作DOM节点技巧总结》、《Java文件与目录操作技巧汇总》和《Java缓存操作技巧汇总》

希望本文所述对大家java程序设计有所帮助。

(0)

相关推荐

  • Java设计模式之工厂模式(Factory模式)介绍

    工厂模式定义:提供创建对象的接口. 为何使用工厂模式 工厂模式是我们最常用的模式了,著名的Jive论坛,就大量使用了工厂模式,工厂模式在Java程序系统可以说是随处可见. 为什么工厂模式是如此常用?因为工厂模式就相当于创建实例对象的new,我们经常要根据类Class生成实例对象,如A a=new A() 工厂模式也是用来创建实例对象的,所以以后new时就要多个心眼,是否可以考虑实用工厂模式,虽然这样做,可能多做一些工作,但会给你系统带来更大的可扩展性和尽量少的修改量. 我们以类Sample为例,

  • Java设计模式之监听器模式实例详解

    本文实例讲述了Java设计模式之监听器模式.分享给大家供大家参考,具体如下: 监听器模式有三个要素--事件源.事件对象.监听器. 事件源:顾名思义,事件发生的源头,比如点击的按钮,属于被监听的对象: 事件对象:这个经常和事件源混淆,它经常被用来包装事件源,切记,它毕竟是个事件,比如点击事件,和事件源的区别自己感受,木有栗子: 监听器:这个是监听器模式的核心,定义事件发生后的动作,通常事件对象作为监听器中定义的函数入参. 下面举个简单的栗子: 故事背景是,小明是个不讲卫生的孩子,他妈妈很担心他的健

  • Java设计模式之责任链模式(Chain of Responsibility模式)介绍

    Chain of Responsibility定义:Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request.也就是说,来了一个请求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去. 如何使用责任链模式 虽然这一段是如何使用CoR,但是也是演示什么是CoR. 有一个Handler接口: 复制代码

  • Java设计模式之Iterator模式介绍

    1.首先定义一个容器Collection接口. 复制代码 代码如下: package com.njupt.zhb.learn.iterator;public interface Collection { void add(Object o); int size(); Iterator iterator();} 2.定义一个Iterator迭代器的接口 复制代码 代码如下: package com.njupt.zhb.learn.iterator;public interface Iterator

  • Java设计模式之桥接模式实例详解

    本文实例讲述了Java设计模式之桥接模式.分享给大家供大家参考,具体如下: 概念: 桥接模式(Bridge Pattern):将抽象部分与它的实现部分分离,使它们都可以独立地变化. 桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量. 什么情况下会用桥接模式? 简单的说就是我们在抽象对象的特征时,对象的特征属性又很抽象,不得不把属性再次抽象. 否则的话,具体子类的数量将会成几何增长,而且不易扩展.没办法维护现有代码. 举例,我们在抽象手机这二个对象时,它的几个属性,如

  • Java运用设计模式中的建造者模式构建项目的实例解析

    1.建造者模式概念 定义: 将一个复杂的对象构建与其表示相分离,使得同样的构建过程可以创建不同的表示: 核心 : 构建与表示分离,同构建不同表示 区别于 抽象工厂模式 : (1)与抽象工厂模式 相似,因为它也可以创建复杂对象.主要的区别是建造者模式着重于 一步步构造一个复杂对象,关注的是零件类型和装配工艺的顺序 .而抽象工厂模式着重于多个系列的产品对象(简单的或是复杂的).建造者模式在最后的一步返回产品,而对于抽象工厂来说,产品是立即返回的. (2)在建造者模式里,有个指导者,由指导者来管理建造

  • Java设计模式之装饰者模式详解和代码实例

    装饰者模式可以给已经存在的对象动态的添加能力.下面,我将会用一个简单的例子来演示一下如何在程序当中使用装饰者模式. 1.装饰者模式 让我们来假设一下,你正在寻找一个女朋友.有很多来自不同国家的女孩,比如:美国,中国,日本,法国等等,他们每个人都有不一样的个性和兴趣爱好,如果需要在程序当中模拟这么一种情况的话,假设每一个女孩就是一个Java类的话,那么就会有成千上万的类,这样子就会造成类的膨胀,而且这样的设计的可扩展性会比较差.因为如果我们需要一个新的女孩,就需要创建一个新的Java类,这实际上也

  • Java设计模式之状态模式(State模式)介绍

    State的定义:不同的状态,不同的行为:或者说,每个状态有着相应的行为. 何时使用状态模式 State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了. 不只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数据库系统中出现频率比较高,我们经常会在一个数据表的尾部,加上property属性含义的字段,用以标识记录中一些特殊

  • Java设计模式之模板模式(Template模式)介绍

    Template模式定义:定义一个操作中算法的骨架,将一些步骤的执行延迟到其子类中. 其实Java的抽象类本来就是Template模式,因此使用很普遍.而且很容易理解和使用,我们直接以示例开始: 复制代码 代码如下: public abstract class Benchmark { /** * 下面操作是我们希望在子类中完成 */ public abstract void benchmark(); /** * 重复执行benchmark次数 */ public final long repea

  • Java开发中的23种设计模式详解(推荐)

    设计模式(Design Patterns)                                   --可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的解决很多问题,每

  • 详解Java设计模式编程中的依赖倒置原则

    定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率.          依赖倒置原则基于这样一个事实:

随机推荐