Java design principles-dependency inversion principle (RPM)

The original definition of the dependency inversion principle (dependence inversion Principle,dip):

• High-level modules should not rely on the underlying modules, both should rely on their abstraction;
• Abstraction should not depend on details;
• Detail should be dependent on abstraction.

The behavior of the dependency inversion principle in the Java language is:

• Dependencies between modules occur through abstraction, and there is no direct dependency between classes, and their dependencies are generated through interfaces or abstract classes;
• An interface or abstract class is not dependent on the implementation class;
• Implements a class-dependent interface or abstract class.

The dependency inversion principle actually requires "interface-oriented programming."

The dependency inversion principle can reduce the coupling between classes, improve the stability of the system, reduce the risk caused by concurrent development, and improve the readability and maintainability of the code.

Cases:

Driver interface

 Public Interface Idriver {     publicvoid  driver (ICar car);     }

Driver Realization Class

 Public class Implements Idriver {     publicvoid  driver (ICar car) {        car.run ();}    }

Automotive interface

 Public Interface ICar {     publicvoid  run ();     }

Automotive Realization Class

 Public class Implements ICar {     publicvoid  run () {        System.out.println ("Mercedes-Benz car starts running ..." );    } }

 Public class Implements ICar {     publicvoid  run () {        System.out.println ("BMW car starts running ...");}    } 

Scene class

 Public class Client {     /**     @param  args     */public      staticvoid  main (string[] args) {        new  Driver ();         New Benz ();        Zhangsan.driver (Benz);    } }

Three ways to rely

As long as you do abstract dependencies, even multi-layered dependency transfer is not afraid!

• Constructor passing dependent object--constructor injection

 Public class Implements idriver {     private  ICar car;           Public Driver (ICar _car) {        this. Car = _car;    }            Public void driver () {        this. Car.run ();    }}

• Setter method passing dependent object--setter Dependency Injection

 public  class  Driver implements   Idriver {          Private   ICar car;  /**   *   @param   car the car to set  */ public  void   Setcar (    ICar car) { this . Car = car;  public  void   driver () { this  .car.run (); } }

• Interface declaration dependent object--Interface injection

 Public class Implements Idriver {     publicvoid  driver (ICar car) {        car.run ();}    }

Essence:

The essence of the dependency inversion principle is that the implementations of each class or model are independent of each other through abstraction (interface or abstract class), and do not interact with each other to achieve loose coupling between modules.

Rules:

• Each class has an interface or abstract class as much as possible, or both abstract classes and interfaces are available;
• The surface type of the variable is as far as interface or abstract class;
• No class should derive from a specific class;
• Try not to overwrite the method of the base class;
• Combined with the Richter replacement principle.

The interface is responsible for defining public properties and methods, and for declaring dependencies with other objects, the abstract class is responsible for the implementation of the common Construction section, implementing the class to accurately implement the business logic, and at the appropriate time to refine the parent class.

Dependency inversion and dependency bias

Relying on the positive is the dependency between classes is a real implementation of the dependency between the class, that is, for the implementation of programming, which is the normal way of thinking, I want to drive Mercedes-Benz rely on Mercedes-Benz, I want to use a laptop directly rely on the notebook computer, and write programs need to be the real world things to abstract, Abstract structure is to have an abstract class and interface, and then we based on the needs of the system design to produce an abstraction between the dependence, instead of people in the traditional thinking of the dependencies between things, "inverted" is from here.

Java design principles-dependency inversion principle (RPM)