Design Pattern : Dependency Inversion Principle

In object-oriented design, the dependency inversion principle is a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).
2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.

The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface.

In many cases, thinking about the interaction in itself as an abstract concept allows the coupling of the components to be reduced without introducing additional coding patterns, allowing only a lighter and less implementation-dependent interaction schema.

When the discovered abstract interaction schema(s) between two modules is/are generic and generalization makes sense, this design principle also leads to the following dependency inversion coding pattern.

package com.activemesa.solid.dip;

import org.javatuples.Triplet;

import java.util.ArrayList;
import java.util.List;
import java.util.Objects;
import java.util.stream.Collectors;

// A. High-level modules should not depend on low-level modules. 
// Both should depend on abstractions.

// B. Abstractions should not depend on details. 
// Details should depend on abstractions.

enum Relationship
{
  PARENT,
  CHILD,
  SIBLING
}

class Person
{
  public String name;
  // dob etc.


  public Person(String name) {
    this.name = name;
  }
}

interface RelationshipBrowser
{
  List<Person> findAllChildrenOf(String name);
}

class Relationships implements RelationshipBrowser
{
  public List<Person> findAllChildrenOf(String name) {

    return relations.stream()
      .filter(x -> Objects.equals(x.getValue0().name, name)
              && x.getValue1() == Relationship.PARENT)
      .map(Triplet::getValue2)
      .collect(Collectors.toList());
  }

  // Triplet class requires javatuples
  private List<Triplet<Person, Relationship, Person>> relations =
    new ArrayList<>();

  public List<Triplet<Person, Relationship, Person>> getRelations() {
    return relations;
  }

  public void addParentAndChild(Person parent, Person child)
  {
    relations.add(new Triplet<>(parent, Relationship.PARENT, child));
    relations.add(new Triplet<>(child, Relationship.CHILD, parent));
  }
}

class Research
{
  public Research(Relationships relationships)
  {
    // high-level: find all of john's children
    List<Triplet<Person, Relationship, Person>> relations = relationships.getRelations();
    relations.stream()
      .filter(x -> x.getValue0().name.equals("John")
              && x.getValue1() == Relationship.PARENT)
      .forEach(ch -> System.out.println("John has a child called " + ch.getValue2().name));
  }

  public Research(RelationshipBrowser browser)
  {
    List<Person> children = browser.findAllChildrenOf("John");
    for (Person child : children)
      System.out.println("John has a child called " + child.name);
  }
}

class DIPDemo
{
  public static void main(String[] args)
  {
    Person parent = new Person("John");
    Person child1 = new Person("Chris");
    Person child2 = new Person("Matt");

    // low-level module
    Relationships relationships = new Relationships();
    relationships.addParentAndChild(parent, child1);
    relationships.addParentAndChild(parent, child2);

    new Research(relationships);
  }
}