Dependency inversion principle

The Dependency Inversion Principle ( DIP;. Eng " dependency inversion principle") is a principle in object-oriented software design. It deals with the dependence of modules.

In general, the dip is given by:

Problem and solution

Object-oriented designs are structured in modules that implement different responsibilities. A common practice is to place the modules in levels. The lower the level of a module, more specifically, the events which it defines. In higher-level modules general procedures to be implemented, which are used by lower-level modules.

If this arrangement is implemented incorrectly, ie modules of higher levels of lower-level modules depend on, a problem arises. Changes in lower-level modules inevitably lead to changes in higher-level modules. But this contradicts the one hand, the actual approach of the hierarchy, on the other hand it leads to cyclic dependencies. This leads to an increased coupling of the modules, which complicate changes in architecture and design unnecessary.

The approach is the inversion of dependency. The higher-level module defines the interface with which it works. Lower-level modules provide the interface.

Example

We consider a simple switch - lamp model. Pressing the switch to the lamp on or off.

A simple implementation in Java:

Public class Lamp {     private boolean on = false;       public void enable () {        on = true;     }       public void off () {        on = false;     } }   public class Switch {     private lamp bulb;     private boolean pressed;       public switch ( lamp lamp ) {        this.lampe = lamp;     }       public void drueckeSchalter () {        = pressured pressured! ;        if ( pressured ) {           lampe.anschalten ();        Else { }           lampe.ausschalten ();        }     } } Switch controls the sequence of behavior and used to lamp. Accordingly, it should belong to a higher-level module. However, the model described violated the ' DIP ', because switch is dependent on lamp. If it is decided that the methods are renamed from lamp switch also needs to be changed.

The fundamental problem is that switch works directly with lamp, which belongs to a lower module. Switch should define for yourself how the object should look like, with which it works.

The solution in Java:

Public interface switch client {     public void geheAn ();     public void geheAus (); }   public class Switch {     private client switch client;     private boolean pressed;       public switch ( switch client client ) {        this.klient = client;     }       public void drueckeSchalter () {        = pressured pressured! ;        if ( pressured ) {           klient.geheAn ();        Else { }           klient.geheAus ();        }     } }   public class LampeDIP switch implements client {     private boolean on = false;       public void geheAn () {        on = true;     }       public void geheAus () {        on = false;     } } The interface client switch belongs to the same module such as switches. More specific modules must implement this interface so that switch can work with them. Thus, the relationship was inverted.

In addition to breaking the dependency a further advantage was developed: switch can now work with any client.

The example goes on and on. Switch itself is probably being used by another module that decides when the switch was pressed. Thus, this module should turn define an interface must implement the switch.