精华内容
参与话题
问答
  • ----依赖倒置定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象; 抽象不应该依赖细节;细节应该依赖抽象 #include "stdafx.h" #include <iostream> using namespace std; #include <s...

    ----开闭原则:
    闭指的是:高层业务的接口高度抽象,不要试图去修改
    开指的是:如果有新的功能增加的话,通过类来实现


    ----依赖倒置定义:
    高层模块不应该依赖低层模块,二者都应该依赖其抽象;
    抽象不应该依赖细节;细节应该依赖抽象

    #include "stdafx.h"
    #include <iostream>
    using namespace std;
    #include <string>
    
    class IReader
    {
    public:
    	virtual string getContents() = 0;
    };
    
    
    class Book:public IReader
    {
    public:
    	virtual string getContents()
    	{
    		return "和尚故事";
    	}
    };
    
    
    class NewsPaper:public IReader
    {
    public:
    	virtual string getContents()
    	{
    		return "川普上任美国总统";
    	}
    };
    
    
    class ElectricBook :public IReader
    {
    public:
    	virtual string getContents()
    	{
    		return  "鬼吹灯";
    	}
    };
    
    
    class Mother
    {
    public:
    	void tellStory(IReader* i)
    	{
    		cout << i->getContents() << endl;
    	}
    };
    
    
    
    int _tmain(int argc, _TCHAR* argv[])
    {
    	Book b;
    
    	NewsPaper n;
    
    	ElectricBook e;
    
    	Mother m;
    	cout << "mother start to tell story:" << endl;
    	m.tellStory(&b); //赋值兼容 将子类地址赋给父类指针
    
    	cout << "mother start to tell American" << endl;
    	m.tellStory(&n);
    
    	cout << "mother start to tell ghost" << endl;
    	m.tellStory(&e);
    
    	return 0;
    }

    关系图片:

     

    展开全文
  • 依赖倒置原则------依赖的三种方法

    千次阅读 2018-05-11 22:27:12
    依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下:High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not depend upon details....


    依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下:

    High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstracts.

    翻译过来为:

    • 高层模块不应该依赖低层模块,两者都应该依赖抽象
    • 抽象不应该依赖细节
    • 细节应该依赖抽象

    也可以说高层模块,低层模块,细节都应该依赖抽象

    每一个逻辑的实现都是由颗粒原子逻辑组成的,颗粒原子逻辑就是低层模块,而颗粒原子逻辑组成的模块就是高层模块。在java语言中,抽象就是接口或抽象类,两都都是不能直接被实例化的,细节就是实现类,实现接口或继承抽象类而产生的类就是细节,两者都可以直接被实例化。

    依赖倒置原则在java语言中,表现是:

    • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的。
    • 接口或抽象类不依赖实现类
    • 实现类依赖接口或抽象类

    更加精简的定义就是“面向接口编程”—OOD(Object-Oriented Design,面向对象设计)的精髓之一。


    依赖倒置原则的好处

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


    为什么我们要符合依赖倒置原则

    我们通过一个例子说明依赖倒置原则对于开发有上面的好处。

    大家都喜欢阅读,阅读文学经典滋润自己的内心心灵,下面是小明同学阅读文学经典的示例:


    文学经典的源代码:


    //文学经典类
    public class LiteraryClassic{
        //阅读文学经典
        public void read(){
           System.out.println("文学经典阅读,滋润自己的内心心灵");
        }
    }



    小明类:

    //小明类
    public class XiaoMing{
        //阅读文学经典
        public void read(LiteraryClassic literaryClassic){
            literaryClassic.read();
        }
    }


    场景类:

    public class Client{
       public static void main(Strings[] args){
          XiaoMing xiaoming = new XiaoMing();
          LiteraryClassic literaryClassic = new LiteraryClassic();
          //小明阅读文学经典
          xiaoming.read(literaryClassic);
       }
    
    }




    看,我们的实现,小明同学可以阅读文学经典了。

    小明同学看了一段文学经典后,忽然他想看看看小说来放松一下自己,我们实现一个小说类:

    小说类源代码

    //小说类
    public class Novel{
        //阅读小说
        public void read(){
           System.out.println("阅读小说,放松自己");
        }
    }


    现在我们再来看代码,发现XiaoMing类的read方法只与文学经典LiteraryClassic类是强依赖,紧耦合关系,小明同学竟然阅读不了小说类。这与现实明显的是不符合的,代码设计的是有问题的。那么问题在那里呢?

    我们看小明类,此类是一个高层模块,并且是一个细节实现类,此类依赖的是一个文学经典LiteraryClassic类,而文学经典LiteraryClassic类也是一个细节实现类。这是不是就与我们说的依赖倒置原则相违背呢?依赖倒置原则是说我们的高层模块,实现类,细节类都应该是依赖与抽象,依赖与接口和抽象类。

    为了解决小明同学阅读小说的问题,我们根据依赖倒置原则先抽象一个阅读者接口,下面是示例:


    IReader接口:

    public interface IReader{
       //阅读
       public void read(IRead read){
           read.read();
       }
    
    }



    再定义一个被阅读的接口IRead:

    public interface IRead{
       //被阅读
       public void read();
    }



    再定义文学经典类和小说类: 

    文学经典类:
    //文学经典类
    public class LiteraryClassic implements IRead{
        //阅读文学经典
        public void read(){
           System.out.println("文学经典阅读,滋润自己的内心心灵");
        }
    }


    小说类:

    //小说类
    public class Novel implements IRead{
        //阅读小说
        public void read(){
           System.out.println("阅读小说,放松自己");
        }
    }


    再实现小明类:

    //小明类
    public class XiaoMing implements IReader{
        //阅读
        public void read(IRead read){
            read.read();
        }
    }


    然后,我们再让小明分别阅读文学经典和小说:

    Client:

    public class Client{
       public static void main(Strings[] args){
          XiaoMing xiaoming = new XiaoMing();
          IRead literaryClassic = new LiteraryClassic();
          //小明阅读文学经典
          xiaoming.read(literaryClassic);
    
          IRead novel = new Novel();
          //小明阅读小说
          xiaoming.read(novel);
       }
    
    }


    至此,小明同学是可以阅读文学经典,又可以阅读小说了,目的达到了。

    为什么依赖抽象的接口可以适应变化的需求?这就要从接口的本质来说,接口就是把一些公司的方法和属性声明,然后具体的业务逻辑是可以在实现接口的具体类中实现的。所以我们当依赖对象是接口时,就可以适应所有的实现此接口的具体类变化。


    依赖的三种方法

    依赖是可以传递,A对象依赖B对象,B又依赖C,C又依赖D,……,依赖不止。只要做到抽象依赖,即使是多层的依赖传递也无所谓惧。 
    对象的依赖关系有三种方式来传递:


    构造函数传递依赖对象

    在类中通过构造函数声明依赖对象,按照依赖注入的说法,这种方式叫做构造函数注入:

    构造函数注入:


    //小明类
    public class XiaoMing implements IReader{
         private IRead read;
         //构造函数注入
         public XiaoMing(IRead read){
            this.read = read;
         }
    
        //阅读
        public void read(){
            read.read();
        }
    }



    Setter方法传递依赖对象

    在类中通过Setter方法声明依赖关系,依照依赖注入的说法,这是Setter依赖注入:

    //小明类
    public class XiaoMing implements IReader{
         private IRead read;
         //Setter依赖注入
         public setRead(IRead read){
            this.read = read;
         }
    
        //阅读
        public void read(){
            read.read();
        }
    }



    接口声明依赖

    在接口的方法中声明依赖对象,在为什么我们要符合依赖倒置原则的例子中,我们采用了接口声明依赖的方式,该方法也叫做接口注入。


    依赖倒置原则的经验

    依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合。我们在项目中使用这个原则要遵循下面的规则:

    • 每个类尽量都有接口或者抽象类,或者抽象类和接口两都具备
    • 变量的表面类型尽量是接口或者抽象类
    • 任何类都不应该从具体类派生
    • 尽量不要覆写基类的方法 
      如果基类是一个抽象类,而这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会有一定的影响。
    • 结合里氏替换原则使用 
      里氏替换原则:父类出现的地方子类就能出现。结合本章我们得出了一个通俗的规则:接口负责定义public属性和方法,并且声明与其他对象的依赖关系。抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。

    依赖倒置原则是6个设计原则中最难以实现的原则,它是实现开闭原则的重要方法,在项目中,大家只要记住是”面向接口编程”就基本上是抓住了依赖倒置原则的核心了。




















    本文转自:

    https://blog.csdn.net/hfreeman2008/article/details/52289571








    展开全文
  • (精)依赖倒置原则

    千次阅读 2014-08-01 10:23:22
    依赖倒置原则(Dependence Inversion Principle),简称DIP。 定义:High level modules should not depend upon low level modules, Both should depend upon abstractions. Abstractions should not depend upon ...
    一、DIP简介(DIP--Dependency Inversion Principle):
    1、高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
    2、抽象不应该依赖于细节,细节应该依赖于抽象。
    高层模块包含了一个应该程序中的重要的策略选择和业务模型,正是这些高层模块才使得其所有的应用程序区别于其他,如果高层依赖于低层,那么对低层模块的改动就会直接影响到高层模块,从而迫使它们依次做出改动。
    二、举例说明:
    反面例子:

    缺点:耦合太紧密,Light发生变化将影响ToggleSwitch。
    解决办法一:
    将Light作成Abstract,然后具体类继承自Light。

    优点:ToggleSwitch依赖于抽象类Light,具有更高的稳定性,而BulbLight与TubeLight继承自Light,可以根据"开放-封闭"原则进行扩展。只要Light不发生变化,BulbLight与TubeLight的变化就不会波及ToggleSwitch。

     

    缺点:如果用ToggleSwitch控制一台电视就很困难了。总不能让TV继承自Light吧。
    解决方法二:
    优点:更为通用、更为稳定。
    三、DIP优点:

     

    使用传统过程化程序设计所创建的依赖关系,策略依赖于细节,这是糟糕的,因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象,抽象的稳定性决定了系统的稳定性。
    、启发式规则:
    1、任何变量都不应该持有一个指向具体类的指针或者引用
    2、任何类都不应该从具体类派生(始于抽象,来自具体)
    3、任何方法都不应该覆写它的任何基类中的已经实现了的方法

     

    ------------------------------------------------------------------

    依赖倒置原则(Dependence Inversion Principle),简称DIP。
     
    定义:High level modules should not depend upon low level modules, Both should depend upon abstractions. Abstractions should not depend upon details, Details should depend upon abstractions.
     
    即:高层模块不应该依赖低层模块,二者都应该依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象。
     
    抽象:即抽象类或接口,是不能够实例化的。
     
    细节:即具体的实现类,实现接口或者继承抽象类所产生的类,可以通过关键字new直接被实例化。
     

     

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

     


    依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
     
    依赖倒置原则其本质就是契约式编程,通过抽象(抽象类或接口)使各个类或模块的实现彼此独立,不相互影响,实现模块间的松耦合。使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。如果没有实现这个原则,那么也就意味着开闭原则(对扩展开发,对修改关闭)也无法实现。
     

     

    在实际编程中,我们一般需要做到如下3点:
    •低层模块尽量都要有抽象类或接口,或者两者都有。
    •变量的声明类型尽量是抽象类或接口。
    •使用继承时遵循里氏替换原则。
     

     

    依赖倒置有三种方式来实现
     
    1、通过构造函数传递依赖对象;
     
    比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。
     
    2、通过setter方法传递依赖对象;
     
    即在我们设置的setXXX方法中的参数为抽象类或接口,来实现传递依赖对象。
     
    3、接口声明实现依赖对象,也叫接口注入;
     
    即在函数声明中参数为抽象类或接口,来实现传递依赖对象,从而达到直接使用依赖对象的目的。
     

     

    为方便理解,举一些生活中的例子:
     
    1、AGP插槽。主板和显卡之间关系的抽象。主板和显卡通常是使用AGP插槽来连接的,这样,只要接口适配,不管是主板还是显卡更换,都不是问题。
     
    2、驾照。司机和汽车之间关系的抽象。有驾照的司机可以驾驶各种汽车。
     
    3、电源插座。
     

     

    设计模式中最能体现DIP原则的是抽象工厂模式。在抽象工厂模式中,工厂和产品都可以是抽象的,如果客户要使用的话,只要关注于工厂和产品的接口即可,不必关注与工厂和产品的具体实现。
     

     

    DIP对于并行开发的影响:两个类之间有依赖关系,只要制定出他们之间的接口,就可以并行开发了。
     

     

    备注:
     
    1、什么叫做高层模块依赖于底层模块?
     
          面向过程的开发时,为了复用一些常用代码,通常会把这些代码写成函数库的形式。这样,以后做新项目时,调用这些底层函数就可以了。这就叫做高层模块依赖于底层模块。
     
    高层模块一般和业务逻辑相关,底层模块一般和具体实现相关。
     
    2、何谓“倒置”?
     

       这是因为传统的软件开发方法,如结构化的分析和设计,倾向于创建高层模块依赖于低层模块、抽象依赖于具体的软件结构。实际上,这些方法的目标之一就是去定义描述上层模块如何调用低层模块的层次结构。所以,相对于传统的过程化的方法通常所产生的那种依赖结构,一个设计良好的面向对象的程序中的依赖结构就是“被倒置”的。
     
        来看一下那些依赖于低层模块的高层模块的含义。一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是,当这些模块依赖于低层模块时,低层模块的修改将会直接影响到它们,迫使它们也去改变。这种境况是荒谬的。应该是处于高层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且,我们想能够复用的是高层的模块。通过子程序库的形式,我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时,这些高层模块就很难在不同的环境中复用。但是,当那些高层模块独立于低层模块时,它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则

     

    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 details. Details should depend upon abstractions。翻译过来,包含三层含义: 

    • 高层模块不应该依赖低层模块,两者都应该依赖其抽象; 
    • 抽象不应该依赖细节; 
    • 细节应该依赖抽象。

         高层模块和低层模块容易理解,每一个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块。那什么是抽象,什么又是细节呢?在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是: 

    • 模块间的依赖是通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的; 
    • 接口或抽象类不依赖于实现类; 
    • 实现类依赖接口或抽象类。

         更加精简的定义就是“面向接口编程”——OOD(Object-Oriented Design,面向对象设计)的精髓之一。 

    3.2 言而无信,你太需要契约

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

         证明一个定理是否正确,有两种常用的方法:一种是根据提出的论题,经过一番论证,推出和定理相同的结论,这是顺推证法;还有一种是首先假设提出的命题是伪命题,然后推导出一个荒谬、与已知条件互斥的结论,这是反证法。我们今天就用反证法来证明依赖倒置原则是多么的优秀和伟大! 

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

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

         我们通过一个例子来说明反论题是不成立的。现在的汽车越来越便宜了,也就顶多一个卫生间的价格就可以买到一辆不错的汽车,有汽车就必然有人来驾驶了,司机驾驶奔驰车的类图如图3-1所示。 

    clip_image002

    图3-1 司机驾驶奔驰车类图 

         奔驰车可以提供一个方法run,代表车辆运行,实现过程如代码清代3-1所示。 

    代码清单3-1 司机源代码

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public class Driver {
    //司机的主要职责就是驾驶汽车
    public void drive(Benz benz){
    benz.run();
    }
    }

         司机通过调用奔驰车的run方法开动奔驰车,其源代码如代码清单3-2所示。

    代码清单3-2 奔驰车源代码

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public class Benz {
    //汽车肯定会跑
    public void run(){
    System.out.println("奔驰汽车开始运行...");
    }
    }

         有车,有司机,在Client场景类产生相应的对象,其源代码如代码清代3-3所示。

    代码清单3-3 场景类源代码

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    public class Client {
    public static void main(String[] args) {
    Driver zhangSan = new Driver();
    Benz benz = new Benz();
    //张三开奔驰车
    zhangSan.drive(benz);
    }
    }

         通过以上的代码,完成了司机开动奔驰车的场景,到目前为止,这个司机开奔驰车的项目没有任何问题。我们常说“危难时刻见真情”,我们把这句话移植到技术上就成了“变更才显真功夫”,业务需求变更永无休止,技术前进就永无止境,在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头:张三司机不仅要开奔驰车,还要开宝马车,又该怎么实现呢?麻烦出来了,那好,我们走一步是一步,我们先把宝马车产生出来,实现过程如代码清单3-4所示。

    代码清单3-4 宝马车源代码

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public class BMW {
    //宝马车当然也可以开动了
    public void run(){
    System.out.println("宝马汽车开始运行...");
    }
    }

         宝马车也产生了,但是我们却没有办法让张三开动起来,为什么?张三没有开动宝马车的方法呀!一个拿有C照的司机竟然只能开奔驰车而不能开宝马车,这也太不合理了!在现实世界都不允许存在这种情况,何况程序还是对现实世界的抽象,我们的设计出现了问题:司机类和奔驰车类之间是一个紧耦合的关系,其导致的结果就是系统的可维护性大大降低,可读性降低,两个相似的类需要阅读两个文件,你乐意吗?还有稳定性,什么是稳定性?固化的、健壮的才是稳定的,这里只是增加了一个车类就需要修改司机类,这不是稳定性,这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本,这样的依赖关系谁肯承担!证明到这里,我们已经知道伪命题已经部分不成立了。

         注意 设计是否具备稳定性,只要适当的“松松土”,观察“设计的蓝图”是否还可以茁壮的成长就可以得出结论,稳定性较高的设计,在周围环境频繁变化的时候,依然可以做到“我自岿然不动”。

         我们继续证明,“减少并行开发引起的风险”,什么是并行开发的风险?并行开发最大的风险就是风险扩散,本来只是一段程序的错误或异常,逐步波及一个功能,一个模块,甚至到最后毁坏了整个项目,为什么并行开发就有这个风险呢?一个团队,20人开发,各人负责不同的功能模块,甲负责汽车类的建造,乙负责司机类的建造,在甲没有完成的情况下,乙是不能完全地编写代码的,缺少汽车类,编译器根本就不会让你通过!在缺少Benz类的情况下,Driver类能编译吗?更不要说是单元测试了!在这种不使用依赖倒置原则的环境中,所有的开发工作都是“单线程”的,甲做完,乙再做,然后是丙继续…,这在90年代“个人英雄主义”编程模式中还是比较适用的,一个人完成所有的代码工作,但在现在的大中型项目中已经是完全不能胜任了,一个项目是一个团队的协作结果,一个“英雄”再牛X也不可能了解所有的业务和所有的技术,要协作就要并行开发,要并行开发就要解决模块之间的项目依赖关系,那然后呢?依赖倒置原则就隆重出场了!

         根据以上证明,如果不使用依赖倒置原则就会加重类间的耦合性,降低系统的稳定性,增加并行开发引起的风险,降低代码的可读性和维护性。承接上面的例子,引入依赖倒置原则后的类图如图3-2所示。

    clip_image004

    图3-2 引入依赖倒置原则后的类图

         建立两个接口:IDriver和ICar,分别定义了司机和汽车的各个职能,司机就是驾驶汽车,必须实现drive()方法,其实现过程如代码清单3-5所示。

    代码清单3-5 司机接口

    1
    2
    3
    4
    5
    6
    7
    public interface IDriver {
    //是司机就应该会驾驶汽车
    public void drive(ICar car);
    }

         接口只是一个抽象化的概念,是对一类事物的最抽象描述,具体的实现代码由相应的实现类来完成,Driver实现类如代码清单3-6所示。

    代码清单3-6 司机类的实现

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public class Driver implements IDriver{
    //司机的主要职责就是驾驶汽车
    public void drive(ICar car){
    car.run();
    }
    }

         在IDriver中,通过传入ICar接口实现了抽象之间的依赖关系,Driver实现类也传入了ICar接口,至于到底是哪个型号的Car需要在高层模块中声明。

         ICar及其两个实现类的实现过程如代码清单3-7所示。

    代码清单3-7 汽车接口及两个实现类

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    public interface ICar {
    //是汽车就应该能跑
    public void run();
    }
    public class Benz implements ICar{
    //汽车肯定会跑
    public void run(){
    System.out.println("奔驰汽车开始运行...");
    }
    }
    public class BMW implements ICar{
    //宝马车当然也可以开动了
    public void run(){
    System.out.println("宝马汽车开始运行...");
    }
    }

         在业务场景中,我们贯彻“抽象不应该依赖细节”,也就是我们认为抽象(ICar接口)不依赖BMW和Benz两个实现类(细节),因此我们在高层次的模块中应用都是抽象,Client的实现过程如代码清单3-8所示。

    代码清单3-8 业务场景

    public class Client {

    public static void main(String[] args) {

    IDriver zhangSan = new Driver();

    ICar benz = new Benz();

    //张三开奔驰车

    zhangSan.drive(benz);

    }

    }

         Client属于高层业务逻辑,它对低层模块的依赖都建立在抽象上,zhangSan的显示类型是IDriver,benz的显示类型是ICar,也许你要问,在这个高层模块中也调用到了低层模块,比如new Driver()和new Benz()等,如何解释?确实如此,zhangSan的显示类型是IDriver,是一个接口,是抽象的,非实体化的,在其后的所有操作中,zhangSan都是以IDriver类型进行操作,屏蔽了细节对抽象的影响。当然,张三如果要开宝马车,也很容易,我们只要修改业务场景类就可以,实现过程如代码清单3-9所示。

    代码清单3-9 张三驾驶宝马车的实现过程

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    public class Client {
    public static void main(String[] args) {
    IDriver zhangSan = new Driver();
    ICar bmw = new BMW();
    //张三开奔驰车
    zhangSan.drive(bmw);
    }
    }

         在新增加低层模块时,只修改了业务场景类,也就是高层模块,对其他低层模块如Driver类不需要做任何修改,业务就可以运行,把“变更”引起的风险扩散降低到最小。

         注意 在Java中,只要定义变量就必然要有类型,一个变量可以有两个类型:显示类型和真实类型,显示类型是在定义的时候赋予的类型,真实类型是对象的类型,如zhangSan的显示类型是IDriver,真实类型是Driver。

         我们再来思考依赖倒转对并行开发的影响。两个类之间有依赖关系,只要制定出两者之间的接口(或抽象类)就可以独立开发了,而且项目之间的单元测试也可以独立的运行,而TDD(Test-Driven Development,测试驱动开发)开发模式就是依赖倒置原则的最高级应用。我们继续回顾上面司机驾驶汽车的例子,甲程序员负责IDriver的开发,乙程序员负责ICar的开发,两个开发人员只要制定好了接口就可以独立地开发了,甲开发进度比较快,完成了IDriver以及相关的实现类Driver的开发工作,而乙程序员滞后开发,那甲是否可以进行单元测试(Unit Test)呢?答案是可以,我们引入一个JMock工具,其最基本的功能是根据抽象虚拟一个对象进行测试,测试类如代码清单3-10所示。

    代码清单3-10 测试类

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    public class DriverTest extends TestCase{
    Mockery context = new JUnit4Mockery();
    @Test
    public void testDriver() {
    //根据接口虚拟一个对象
    final ICar car = context.mock(ICar.class);
    IDriver driver = new Driver();
    //内部类
    context.checking(new Expectations(){{
    oneOf (car).run();
    }});
    driver.drive(car);
    }
    }

         注意粗体部分,我们只需要一个ICar的接口,就可以对Driver类进行单元测试,从这一点来看,两个相互依赖的对象可以分别进行开发,孤立的单元测试,进而保证并行开发的效率和质量,TDD开发的精髓不就在这里吗?测试驱动开发,先写好单元测试类,然后再写实现类,这对代码的质量有非常大的提高,特别适合研发类项目或在项目成员整体水平比较低的情况下采用。

         抽象是对实现的约束,对依赖者而言,也是一种契约,不仅仅约束自己,还同时约束自己与外部的关系,其目的是保证所有的细节不逃脱契约的范畴,确保约束双方按照既定的契约(抽象)共同发展,只要抽象这根基线在,细节就逃脱不了这个圈圈,始终让你的对象做到“言而有信”“言出必行”

    3.3 依赖的三种写法

         依赖是可以传递的,A对象依赖B对象,B又依赖C,C又依赖D…,生生不息,依赖不止,记住一点:只要做到抽象依赖,即使是多层的依赖传递也无所畏惧!

         对象的依赖关系有三种方式来传递,如下所示。

    • 构造函数传递依赖对象

         在类中通过构造函数声明依赖对象,按照依赖注入的说法这种方式叫做构造函数注入,按照这种方式的注入,IDriver和Driver的程序修改后如代码清单3-11所示。

    代码清单3-11 构造函数传递依赖对象

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    public interface IDriver {
    //是司机就应该会驾驶汽车
    public void drive();
    }
    public class Driver implements IDriver{
    private ICar car;
    //构造函数注入
    public Driver(ICar _car){
    this.car = _car;
    }
    //司机的主要职责就是驾驶汽车
    public void drive(){
    this.car.run();
    }
    }
    • Setter方法传递依赖对象

         在抽象中设置setter方法声明依赖关系,依照依赖注入的说法就是setter依赖注入,按照这种方式的注入,IDriver和Driver的程序修改后如代码清单3-12所示。

    代码清单3-12 Setter依赖注入

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    public interface IDriver {
    //车辆型号
    public void setCar(ICar car);
    //是司机就应该会驾驶汽车
    public void drive();
    }
    public class Driver implements IDriver{
    private ICar car;
    public void setCar(ICar car){
    this.car = car;
    }
    //司机的主要职责就是驾驶汽车
    public void drive(){
    this.car.run();
    }
    }
    • 接口声明依赖对象

         在接口的方法中声明依赖对象,3.2章节的例子就是采用了接口声明依赖的方式,,该方法也叫做接口注入。

    3.4 最佳实践

         依赖倒转原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合,我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:

    • 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备。

         这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置。

    • 变量的显示类型尽量是接口或者是抽象类。

         很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了,比如一个工具类,xxxUtils一般是不需要接口或是抽象类的。还有,如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供一个规范。

    • 任何类都不应该从具体类派生。

         如果一个项目处于开发状态,确实不应该有从具体类派生出的子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此只要不超过两层的继承都是可以忍受的。特别是做项目维护的同志,基本上可以不考虑这个规则,为什么?维护工作基本上都是做扩展开发,修复行为,通过一个继承关系,覆写一个方法就可以修正一个很大的Bug,何必再要去继承最高的基类呢?

    • 尽量不要覆写基类的方法。

         如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。

    • 结合里氏替换原则使用

         在上一个章节中我们讲解了里氏替换原则,父类出现的地方子类就能出现,再结合本章节的讲解,我们可以得出这样一个通俗的规则: 接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。

         讲了这么多,估计大家对“倒置”这个词还是有点不理解,那到底什么是“倒置”呢?我们先说“正置”是什么意思,依赖正置就是类间的依赖是实实在在的实现类间的依赖,也就是面向实现编程,这也是正常人的思维方式,我要开奔驰车就依赖奔驰车,我要使用笔记本电脑就直接依赖笔记本电脑,而编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖,“倒置”就是从这里产生的。

         依赖倒置原则的优点在小型项目中很难体现出来,例如小于10个人月的项目,使用简单的SSH架构,基本上不费太大力气就可以完成,是否采用依赖倒置原则影响不大。但是,在一个大中型项目中,采用依赖倒置原则可以带来非常多的优点,特别是规避一些非技术因素引起的问题。项目越大,需求变化的概率也越大,通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束,可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的,如果设计优良、代码结构清晰,人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长,采用依赖倒置原则可以让维护人员轻松地扩展和维护。

         依赖倒置原则是六个设计原则中最难以实现的原则,它是实现开闭原则的重要途径,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭。在项目中,大家只要记住是“面向接口编程”就基本上抓住了依赖倒转原则的核心。

         讲了这么多依赖倒置原则的优点,我们也来打击一下大家,在现实世界中确实存在着必须依赖细节的事物,比如法律,就必须依赖细节的定义。 “杀人偿命”在中国的法律中古今有之,那这里的杀人就是一个抽象的含义,怎么杀,杀什么人,为什么杀人,都没有定义,只要是杀人就统统得偿命,那这就是有问题了,好人杀了坏人,还要陪上自己的一条性命,这是不公正的,从这一点看,我们在实际的项目中使用依赖倒置原则时需要审时度势,不要抓住一个原则不放,每一个原则的优点都是有限度的,并不是放之四海而皆准的真理,所以别为了遵循一个原则而放弃了一个项目的终极目标:投产上线和盈利。作为一个项目经理或架构师,应该懂得技术只是实现目的的工具,惹恼了顶头上司,设计做得再漂亮,代码写得再完美,项目做得再符合标准,一旦项目亏本,产品投入大于产出,那整体就是扯淡!你自己也别想混得更好!

     

    展开全文
  • 如何理解依赖倒置原则?

    千次阅读 2017-02-06 19:18:52
    ------ 读书心得 ------- ...看看依赖倒置是怎样解决这个问题的?它的两个原则: 1. 高层模块不该依赖于低层模块, 二者都该依赖于抽象 2. 抽象不应该依赖于细节,细节应该依赖于抽象 看下图,在层之

    ------  读书心得 -------

    通常情况的设计都是高层模块依赖于低层模块。这样看似顺理成章,低层模块不怎么变动,高层模块调用低层模块。但是事实上,事物总是在变化,经常低层模块变化,引起高层一系列的变化。


    看看依赖倒置是怎样解决这个问题的?它的两个原则:

    1. 高层模块不该依赖于低层模块, 二者都该依赖于抽象

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

    看下图,在层之间加入接口抽象类。低层模块依赖于高层的抽象接口。这样就解决了,低层模块变动,高层模块也得改动的问题。而且,低层服务换了,高层也不需要改动。这就是依赖倒置。

     第二个原则里的细节是指低层逻辑。高层通常称为策略,业务。低层叫细节。所以是细节依赖于抽象。也就是低层模块的实现必须符合高层定义的接口标准,这是增加了限制。


    通过依赖倒置,我们可以看出,大家都依赖于抽象是一个很好的解决方案。势必通过依赖倒置得到下面规则:

    1. 任何变量,类都不应该有一个指向具体类的指针或者引用

    2. 任何类都不该从具体类派生

    3. 任何方法都不该覆写它的任何基类中已经实现了的方法。


    依赖倒置是面向对象的标志。


    SOLID 五项原则介绍:

     如何理解单一职责原则?

     如何理解接口隔离原则?

     如何理解开放封闭原则?

     如何理解里氏替换原则?

     如何理解依赖倒置原则?


    展开全文
  • 依赖倒置原则

    千次阅读 2018-10-24 16:20:52
    一,依赖倒置原则 1.1,什么是依赖倒置? 高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。抽象不应该依赖于具体实现,具体实现应该依赖于抽象。也就是说要面向接口编程,不能面向实现编程。 1.2,...
  • 六大设计原则之依赖倒置原则

    万次阅读 2016-08-23 11:42:52
    依赖倒置原则定义依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下:High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not ...
  • 面向对象六大原则——依赖倒置原则

    万次阅读 多人点赞 2018-08-13 10:56:49
    什么是依赖倒置原则(Dependence Inversion Principle, DIP)  依赖倒置原则的包含如下的三层含义: - 高层模块不应该依赖低层模块,两者都应该依赖其抽象 - 抽象不应该依赖细节 - 细节应该依赖抽象  每一个...
  • 之前我们对设计模式的六大原则做了简单归纳,这篇博客是对依赖倒置原则进行的举例说明。 依赖倒置原则的意义DIP是6大原则中最难以实现的原则,它是实现开闭原则的重要途径,DIP没有实现,就别想实现对扩展开放,对...
  • 依赖倒置原则定义 如下(可先不管) - 高层模块不应该依赖低层模块,两者都应该依赖抽象 - 抽象不应该依赖细节 - 细节应该依赖抽象 情景描述 当前有一家饮料店,里面卖着很多饮料 设计如下 问题...
  • 如果你错过了前四篇文章,你可以很容易的从这里开始:S: 单一职责原则O: 开、闭原则L: 里氏替换原则I: 接口隔离原则D: 依赖倒置原则 (本文)不再做广告了,我们第五篇最后的原则 -依赖倒置原则描述的是作为开发者你...
  • 设计模式六大原则(3):依赖倒置原则

    万次阅读 多人点赞 2012-02-24 08:46:12
    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是...
  • 依赖倒置原则

    2013-12-12 15:48:39
    设计模式六大原则(3):依赖倒置原则 (转载)   定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则...
  • java专题——依赖倒置原则

    千次阅读 2014-09-14 12:41:31
    依赖倒置原则 3.1 依赖倒置原则的定义  依赖倒置原则(Dependence Inversion Principle,简称DIP)这个名字看着有点别扭,“依赖”还“倒置”,这到底是什么意思?依赖倒置原则的原始定义是:High level ...
  • c++依赖倒置原则

    千次阅读 2017-10-17 13:19:42
    C++依赖倒置原则
  • 依赖倒置原则(设计模式原则)

    千次阅读 2018-01-14 00:02:27
    (Dependence Inversion Principle)定义: 高层模块不应该依赖底层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。//“抽象”指“接口或抽象类”,“细节”指“实现类” 在语言中表现:  ...
  • 闲话-依赖倒置原则

    2019-04-29 11:29:17
    依赖倒置原则 本质 :高层模块不因该直接依赖于底层模块的实现,而应该依赖于底层模块的抽象。即,模块类之间的依赖是基于抽象类的,实现类之间不能有直接的依赖关系,其依赖关系是通过接口或者抽象类产生的。另外...
  • 关于依赖倒置原则

    2017-11-14 16:28:00
    依赖倒置原则(Dependence Inversion Principle,DIP)这个名字看着有点别扭,“依赖”还“倒置”,这到底是什么意思?依赖倒置原则的原始定义是 High level modules should not depend upon low level modules.Both ...
  • 依赖倒置原则实例讲解

    千次阅读 2012-03-07 16:35:00
     所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。  意图:  面向过程的...
  • Unity 依赖倒置原则

    2018-10-31 22:14:00
    1.定义 高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。 以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。...依赖倒置原则的核心思想是面向接口...
  • 依赖倒置原则和接口隔离原则的记录。 依赖倒置原则:高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象; 接口隔离原则:建立单一接口,不要建立臃肿庞大的接口;
  • 吐槽 依赖倒置原则/DIP

    千次阅读 2017-04-29 00:02:11
    正文(这个比较难写,不能够喜怒笑骂)本文吐槽 依赖倒置原则(Dependency Inversion Principle、DIP)。 即使yqj2065清楚地知道Robert C. Martin想说的东西,这么胡言乱语的神经病的东西,要逐一地指出其问题,差...
  • 依赖倒置原则(Dependency Inversion Principle,DIP)也称依赖反转原则,是面向对象设计(OOD)中比较重要、常见的一种,总结知识点包括:1、什么是依赖倒置原则?2、为什么需要遵守依赖倒置原则?3、在面向对象...
  • 设计模式原则:依赖倒置原则 通常情况的设计都是高层模块依赖于低层模块。这样看似顺理成章,低层模块不怎么变动,高层模块调用低层模块。但是事实上,事物总是在变化,经常低层模块变化,引起高层一系列的变化。 ...
  • 依赖倒置原则 1 高层级的模块不应该依赖于低层次的模块,它应该依赖于低层次模块的抽象 2 抽象不应该依赖于具体,具体应该依赖于抽象 1 高层次的模块不应该依赖于低层次的模型,它应该依赖于低层次模块的抽象 ...

空空如也

1 2 3 4 5 ... 20
收藏数 32,898
精华内容 13,159
关键字:

依赖倒置