设计模式六大原则--依赖倒转原则

       背景

       前段时间有同学感觉自己电脑内存不够用了想买个内存条,只看她在网上捣鼓了一会就搞定了。也没见她看内存条的具体型号是否可以在其电脑上使用等等知识。一时不得其解,网上查了查才知道电脑的硬件是面向接口设计的,最近正好在学习设计模式,我想这是不是和设计模式中的依赖倒转原则有点关系。下面就让小生带领大家详细了解一下“依赖倒转原则(Dependence Inversion Principle)”吧。

       定义

       1、高层模块不应该依赖底层模块,两者都应该依赖抽象。

       2、抽象不应该依赖于细节,细节应该依赖于抽象。

       (原意:High level modules should not dependupon low level modules. Both should depend upon abstractions. Abstractionsshould not depend upon details. Details should depend upon abstractions)

       详细说明

       依赖倒转其实可以说是面向对象设计的标志,用那种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象编程而不是针对细节编程。

       示例

       假设我们有一个上层类Manager和底层类Worker。我们需要在程序中添加一个新模块,为此我们创建一个新的类SuperWorker。

       我们假设Manager是一个包含非常复杂的逻辑的类,现在引入新的SuperWorker,我们需要修改它。这样Manager类中一些现有功能可能受到影响,我们需要重新做单元测试,和其他一系列的问题。

所有的问题我们需要用大量的时间去解决,但是如果程序的设计符合依赖倒转原则将会非常简单。我们可以设计一个接口IWorker,让Worker类去实现它。当需要添加SuperWorker类时,我们只需要让它实现IWorker接口即可,这样就避免了Manger类的改动。

       下面是不符合依赖倒转原则的代码。

 //Dependency Inversion Priciple-Bad example
    class Worker
    {
        public void Work()
        {
            //......working
        }
    }

    class Manager
    {
        Worker worker = new Worker();

        public void SetWorker(Worker w)
        {
            worker = w;
        }

        public void Manage()
        {
            worker.Work();
        }
    }

    class SuperWorker
    {
        public void Work()
        {
            //......working much more
        }
    }

       下面是支持依赖倒转原则的代码。增加一个新的抽象层IWork接口。使得增添SuperWorker累世不需要修改Manager类使其对Manager类现有功能的影响最小化。

//Dependency Inversion Priciple-Good example
    interface IWorker
    {
        public void Work();
    }
    class Worker:IWorker
    {
        public void Work()
        {
            //......working
        }
    }

    class SuperWorker : IWorker
    {
        public void Work()
        {
            //......working much more
        }
    }

    class Manager
    {
        Worker worker = new Worker();

        public void SetWorker(Worker w)
        {
            worker = w;
        }

        public void Manage()
        {
            worker.Work();
        }
    }

(实例来源:http://zjliu.iteye.com/blog/423221#,与此同时设计模式中大量的用到了这个原则,想深入研究的朋友可以了解一下)

       优点

       采用依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,减少并行开发引起的风险,提高代码的可读性和可维护性。

时间: 2024-07-29 10:22:20

设计模式六大原则--依赖倒转原则的相关文章

设计模式学习:依赖倒转原则

依赖: DIP(DependenceInversion Principal),再说这个原则之前,我们先说说什么是依赖吧.这里的依赖关系我们理解为UML关系中的依赖.简单的说就是A use a B,那么A对B产生了依赖.具体请看下面的例子. 图一 从上面的途中我们可以看到,类A的方法func中用到了B,其实我们可以就这么理解,当A中用到了B,那么我们就说A对B产生了依赖,不过请你注意下,不是声明了就是,请看下面的,这种关系叫做零耦合关系,具体可以看下面依赖关系分类. 图2 依赖关系种类: 1) 

设计模式之禅之六大设计原则-依赖倒置原则

依赖倒置原则依赖倒置原则的原始定义是:● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;● 抽象不应该依赖细节;● 细节应该依赖抽象. 那什么是抽象?什么又是细节呢?---->在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象.依赖倒置原则在Java语言中的表现就是: ● 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接

依赖倒转原则

依赖倒转原则: 强内聚:像CPU一样,别的厂商木有办法造.因为看不见内部. 松耦合:像CPU的针脚一样,主板厂商知道怎么造主板能用cpu   依赖倒转原则:抽象不应该依赖结节,细节不应该依赖于抽象.说白了就是针对接口编程,而不是针对实现编程.   依赖倒转原则: 高层模块不应该依赖低层模块.两个都应该依赖抽象. 抽象不应该依赖结节.细节应该依赖抽象.   有些时候为了代码复用,一般会把常用的代码写成函数或类库.这样开发新项目时,直接用就行了.比如做项目时大多要访问数据库,所以我们就把访问数据库的

设计模式六大原则 依赖倒置原则

设计模式六大原则(3): 依赖倒置原则 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 所谓依赖倒置原则(Dependence Inversion Principle )就是要依赖于抽象,不要依赖于具体.简单的说就是对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合. 依赖倒置原则的核心思想是面向接口编程. 而面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变化时,上层也要跟着变化,这就会导致模块的复用性降低而且大大提高

设计模式六大原则---依赖倒置原则(DIP)

    定义    依赖倒置原则(Dependency Inversion Principle)     核心思想:依赖于抽象     具体体现:         体现一:高层模块不应该依赖低层模块.两个都应该依赖抽象.         体现二:抽象不应该依赖细节.细节应该依赖抽象.     依赖倒置原则告诉我们:细节是多变的,而抽象是相对稳定的.所以我们编程的时候要注重抽象的编程,而非细节编程.      实例     1.AGP插槽:主板和显卡之间的关系的抽象.主板和显卡通常是使用AGP插槽

设计模式原则(单一、开放封闭、里氏代换、依赖倒转、迪米特法则五大原则)

原文:设计模式原则(单一.开放封闭.里氏代换.依赖倒转.迪米特法则五大原则) 单一职责原则 单一职责原则,就一个类而言,应该仅有一个引起它变化的原因.   如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力,当变化发生时,设计会遭受到意想不到的破坏.事实上,我们完全可以找出来进行分类,分离.   软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离.其实要去判断是否应该分离出类来,也不难,那就是如果你能够想到多余一个的动机去改变

一句话评论设计模式六大原则

原文链接:http://www.cnblogs.com/lancidie/archive/2012/02/03/2337168.html        原则,故名思议则是本质的意思.所谓擒贼先擒王,研究设计模式自然要先了解设计原则,所有的模式都是在这些原则的基础之上发展起来的,有的是侧重一个,有的是多个都有所涉及.看完设计模式之后,我感觉到每个模式都有这些原则的影子,还渗透着面向对象的三大属性,也觉得这些原则也都有相通之处,,正是有了他们才使我们由代码工人转为艺术家.下面我来点评一下六大原则,望

设计模式之--依赖倒置原则

1.什么是依赖倒转原则? 所谓依赖倒置原则,就是不论高层组件和低层组件都应该依赖于抽象,而不是具体实现类.听起来更像是"针对接口编程,而不是针对实现编程",但是这里依赖倒置原则更强调"抽象"的概念,不要让高层组件依赖低层组件,更不能依赖具体实现类,都要依赖于抽象.依赖倒置原则的核心在于"面向接口编程",目的在于"解耦". 2.这里的倒置是什么意思呢? 依赖倒置原则中的倒置是指我们的思想要和一般的"自顶向下"

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

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