java设计模式理解依赖于抽象不依赖具体的分析

在面向对象设计原则中，要求"要依赖于抽象,不要依赖于具体", 这句话有很多人搞不懂。在这里谈谈我自己的理解。首先看看以下代码

class A{
 public void swim(){
    Dog dog = new Dog();
    dog.move();
  }
}

swim方法中定义了一个Dog的对象，那么无论哪个对象调用这个方法时，一定是"狗爬"，swim和Dog的对象是紧耦合的关系，我们想换成鸭子是不可能。

假如代码这样换一下，我们定义一个动物的接口，接口定义一个move方法。

interface Animal
{
   void move();
}

让狗和鸭子实现该接口，代码如下

public class Dog implements Animal
{
   override
   public void move(){
     //狗爬
   }
}
public class Duck implements Animal
{
   override
   public void move(){
     //八字步
   }
}

class A代码改成如下代码：

class A
{
  private Animal animal;
  public A(Animal animal)
  {
      this.animal = animal;
  }

  public void swim(){
    animal.move();
  }
}

class A依赖于接口（抽象）Animal，和狗、鸭子（具体）没有一点关系，当我们注入的对象是狗，则执行狗爬，当我们注入的对象是鸭子，则执行的是八字步。这就是“要依赖于抽象,不要依赖于具体”具体含义。这样的好处是程序很好扩展，如果想使用青蛙游泳时，我只需要创建一个实现Animal接口的青蛙类，将青蛙的对象注入A类中，便可以执行青蛙的蛙泳了，A中的代码完全闭合。

以上就是java设计模式理解依赖于抽象不依赖具体分析的详细内容，更多关于java依赖抽象设计模式的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • Java设计模式编程中简单工厂与抽象工厂模式的使用实例

    Java设计模式编程中简单工厂与抽象工厂模式的使用实例

    简单工厂模式 类图 通过一个工厂类,以一个条件来创建对应的对象 //业务功能 public interface ICalculation { double getResult(double numA, double numB); } public class CalcAdd implements ICalculation { @Override public double getResult(double numA, double numB) { System.out.println("加法&q

  • Java 23种设计模型详解

    Java 23种设计模型详解

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

  • Java依赖倒转原则_动力节点Java学院整理

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

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

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

  • 浅谈Java设计模式之七大设计原则

    浅谈Java设计模式之七大设计原则

    前言 学习设计模式的方法:掌握理解七大原则以及其目的,学习相应的设计模式(带着设计目的,应用场景(解决什么样的问题),如何实现(编码实现一个小例子),优缺点是什么?等等) 一.单一职责原则(SingleResponsibilityPrinciple,SRP) 定义:一个类只负责一个功能领域中的相应职责 理解:该设计模式很好理解,就是一个类只实现某个领域的相应职责,这样有利于进行调用.就比如在Java开发时,设计controller.service.manager.dao层一样的道理,进行分层分工

  • java设计模式理解依赖于抽象不依赖具体的分析

    在面向对象设计原则中,要求"要依赖于抽象,不要依赖于具体", 这句话有很多人搞不懂.在这里谈谈我自己的理解.首先看看以下代码 class A{ public void swim(){ Dog dog = new Dog(); dog.move(); } } swim方法中定义了一个Dog的对象,那么无论哪个对象调用这个方法时,一定是"狗爬",swim和Dog的对象是紧耦合的关系,我们想换成鸭子是不可能. 假如代码这样换一下,我们定义一个动物的接口,接口定义一个mov

  • 详解java设计模式之六大原则

    详解java设计模式之六大原则

    一.单一职责原则 1.单一职责定义 单一职责原则:一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太"累"!在软件系统中,一个类承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责 变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封

  • Java设计模式——工厂设计模式详解

    工厂模式:主要用来实例化有共同接口的类,工厂模式可以动态决定应该实例化那一个类. 工厂模式的形态 工厂模式主要用一下几种形态: 1:简单工厂(Simple Factory). 2:工厂方法(Factory Method). 3:抽象工厂(Abstract Factory). 简单工厂(Simple Factory) 又叫静态工厂,是工厂模式三中状态中结构最为简单的.主要有一个静态方法,用来接受参数,并根据参数来决定返回实现同一接口的不同类的实例.我们来看一个具体的例子: 假设一家工厂,几生产洗衣

  • Java设计模式之Builder建造者模式

    一.场景描述 建造者模式同工厂模式.抽象工厂模式一样,用于创建继承类对象. 工厂模式:Java设计模式之工厂模式 抽象工厂模式:Java设计模式之抽象工厂模式 所不同的是,工厂模式下,各子类实现接口,通过工厂类创建子类对象:而建造者模式下,各子类拥有其建造者类,通过它创建不同的父类对象,最终实现多态,实际上子类.父类在代码中是不存在的. 以仪器数据采集工具为例,工厂模式下,定义接口"仪器数据采集工具",定义子类"PDF文件数据采集工具"和"Excel文件数

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

    本文实例讲述了java 设计模式之依赖倒置.分享给大家供大家参考,具体如下: 依赖倒置的概念我也是在一篇博文上理解的,我觉得很精辟,所以收录在我的博客中. 类A 依赖 类B,之后根据需求 类A 变换为依赖 类C,这时候我们认为类A 是高层模块, 类B 和 类C 是低层模块. 什么是高层模块?什么是底层模块? 高层模块你可以理解为控制层,负责复杂的业务逻辑. 低层模块你可以理解为数据层,负责基本的原子操作. 什么意思? 我举个例子. 比如大胃王比赛. 在这场比赛中的规则是比赛谁吃馒头吃的最多.有参

  • Java 深入理解创建型设计模式之抽象工厂模式

    Java 深入理解创建型设计模式之抽象工厂模式

    1.什么是抽象工厂模式? 抽象工厂模式:  定义了一个interface用于创建相关或有依赖关系的对象簇,而无需指明具体的类. 抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合. 从设计层面看,抽象工厂模式就是对简单工厂模式的改进(或者称为进一步的抽象). 将工厂抽象成两层,AbsFactory(抽象工厂))和具体实现的工厂子类.程序员可以根据创建对象类型使用对应的工厂子类.这样将单个的简单工厂类变成了工厂簇,更利于代码的维护和扩展. 我们仍然以上一篇文章的案例为主,画出抽象工厂模式下的类图

  • Java设计模式之依赖倒转原则精解

    Java设计模式之依赖倒转原则精解

    目录 1.什么是依赖倒转原则? 2.代码案例 3.依赖关系传递的三种方式和案例举例 3.1 接口传递 3.2 构造方法传递 3.3 setter方法传递 4.依赖倒转原则总结 1.什么是依赖倒转原则? 高层模块不应该依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 依赖倒转 (倒置) 的中心思想是面向接口编程. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在Java中,抽象指的是接口

  • Java设计模式七大原则之依赖倒置原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 依赖倒转原则,又称依赖倒置原则(Dependence Inversion Principle),又称DIP原则,即:上层模块不应该依赖底层模块,它们都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象.抽象对代码来说即接口或者抽象类 细节对代码来说即实现类.换句话说 依赖倒转原则的核心的理念 相对于细节来说,抽象要稳定得多.要求我们 面向接口编程,进行设计. 案例 需求 工作人员接收微信老板发来的加班消息 方案一 定义工作人员W

  • java设计模式七大原则之依赖倒转原则详解

    java设计模式七大原则之依赖倒转原则详解

    目录 1.什么是依赖倒转原则? 2.代码案例 3.依赖关系传递的三种方式和案例举例 3.1 接口传递 3.2 构造方法传递 3.3 setter方法传递 4.依赖倒转原则总结 1.什么是依赖倒转原则? 高层模块不应该依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 依赖倒转 (倒置) 的中心思想是面向接口编程. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在Java中,抽象指的是接口

随机推荐