七大原则三-->依赖倒转原则

依赖倒转原则

1) 高层模块不应该依赖低层模块,二者都应该依赖其抽象
2) 抽象不应该依赖细节,细节应该依赖抽象
3) 依赖倒转(倒置)的中心思想是面向接口编程
4) 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的
多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中,抽象
指的是接口或抽象类,细节就是具体的实现类
5) 使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的
任务交给他们的实现类去完成

需求 Person类接受消息

下面代码 违反了依赖倒转原则

Person 类 接受消息

* 将Email类 作为参数 产生了依赖
* 如果 参数发生变化 即接受的是微信 或短信 整个方法需要改动

package com.wf.zhang.inversion;

public class DependecyInversion {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

class Email{
    public String getInfo() {
        return "电子邮件信息: hello world ";
    }
}
/**
 *  Person 类 接受消息
 *  将Email类 作为参数  产生了依赖
 *  如果 参数发生变化   即接受的是微信 或短信 整个方法需要改动
 * @author wf.zhang
 *
 */
class Person{
    public void receive(Email email) {
        System.out.println(email.getInfo());
    }
}

解决 定义接受的接口   调用时传入不同的实现类  实现不同的接受

package com.wf.zhang.inversion.improve;

public class DependecyInversion2 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
        //传入不同实现类 实现不同的接受
        person.receive(new WenXin());
    }
}
/**
 * 定义接受的接口
 * @author wf.zhang
 *
 */
interface IReciver{
    public String getInfo();

}

class Email implements IReciver{
    public String getInfo() {
        return "电子邮件信息: hello world ";
    }
}
class WenXin implements IReciver{
    public String getInfo() {
        return "微信信息: hello WenXin ";
    }
}

/**
 *  Person 类 接受消息
 *  将IReciver 接口 作为参数  产生了依赖
 * @author wf.zhang
 *
 */
class Person{
    public void receive(IReciver reciver) {
        System.out.println(reciver.getInfo());
    }
}

原文地址:https://www.cnblogs.com/wf-zhang/p/12304508.html

时间: 2024-11-09 03:59:49

七大原则三-->依赖倒转原则的相关文章

面向对象设计原则之依赖倒转原则

如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现.依赖倒转原则是Robert C. Martin在1996年为“C++Reporter”所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作“Agile Software Development, Principles, Patterns, and Practices”一书中.依赖倒转原则定义如下: 依赖倒转原则(Dependency

三、单一职责原则、开放-封闭原则、依赖倒转原则

一.单一职责原则 1.定义:就一个类而言,应该仅有一个引起它变化的原因. 2.为什么要?:如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 3.软件设计真正要做的许多内容,就是发现职责并把职责相互分离. 如果你能想到多余一个动机去改变一个类,那么这个类就具有多于一个原则. 4.示例:设计俄罗斯方块的游戏 可以分为游戏逻辑和界面表示逻辑. 游戏逻辑--数组每一项的值改

[Python设计模式] 第3~5章 单一职责原则/开放-封闭原则/依赖倒转原则

单一职责原则 就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把哪些职责相互分离.如果你能够想到多余一个的动机去改变一个类,那么这个类就具有多余一个的职责,就应该考虑类的职责分离. 开放-封闭原则 开放-封闭原则,是说软件实体(类,模块,函数等)应该可以扩展,但是不可修改.即对

设计模式六大原则(三)——依赖倒置原则

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

第五话-依赖倒转原则

 哎,真是纠结.2011年买的笔记本,2G内存,320G硬盘,i3处理器.现在用着好卡呀.呜呜.怎么办?买个新的吧太贵了,5K呀.还好,可以买个4G内存,再买个1T硬盘.加起来顶多1K哦,同样感受飞一般的感觉.太好了. 可是,我2012年买的手机好卡呀.配置好低呀.呜呜,iphone6都出了.4G时代都流行了,NFC功能爽歪歪.哎,只好换了! 为什么电脑可以换零件,手机就不能呢?这是因为,Computer在设计时非常注重面向对象的思想哦.这就是面向对象的好处. 那么什么才是真正的面向对象呢?

设计模式之刘伟老师文章学习记录-------------依赖倒转原则

如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现.依赖倒转原则是Robert C. Martin在1996年为"C++Reporter"所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作"Agile Software Development, Principles, Patterns, and Practices"一书中.依赖倒转原则定义如下: 依赖倒

设计模式之依赖倒转原则(DIP)

1.概念 DIP:Dependency Inversion Principle 抽象不应当依赖于细节,细节应当依赖于抽象(说通俗点也就是要针对接口编程,不要针对实现编程:或者要依赖于抽象,不要依赖于具体). 2.为何叫"依赖倒转"? 传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块:抽象层次依赖于具体层次.倒转原则则是把这个错误的依赖关系倒过来. 3.如何做到依赖倒转? 以抽象方式耦合是依赖倒转原则的关键.由于一个抽象耦合关系总要涉及到具体类从抽象类继承,并且需要保证在

【转载】依赖倒转原则

3.1 依赖倒置原则的定义 依赖倒置原则(Dependence Inversion Principle,简称DIP)这个名字看着有点别扭,"依赖"还"倒置",这到底是什么意思?依赖倒置原则的原始定义是:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon

大话设计模式之依赖倒转原则

依赖倒转原则: 定义: 在大话中最重要的两句话是:抽象不应该依赖与细节,细节应该依赖于抽象.还有一句是:针对接口编程,不要对实现编程. 问题: 类A直接依赖类B.假如要将类A改为依赖C.则必须通过须要改动类A的代码来达成.但假设,类A是高级模块,负责业务逻辑:类B和类C是低层模块.负责主要的源自操作.这样改变A会给程序带来不必要的风险. 解决方式: 将类A改动为依赖接口I,类B和类C各自实现接口I,类A通过接口I来与类B和C发生纤细,则会大大减少改动A的几率. 基本思想: 用抽象构建框架.用事先