DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > SOLID Principles: Dependency Inversion Principle

SOLID Principles: Dependency Inversion Principle

Here's a breezy walkthrough of the D in SOLID — dependency inversion. Read up on its core tenets and how to refactor code that breaks it.

Emmanouil Gkatziouras user avatar by
Emmanouil Gkatziouras
CORE ·
May. 04, 18 · Java Zone · Tutorial
Like (13)
Save
Tweet
77.65K Views

Join the DZone community and get the full member experience.

Join For Free

Up until now, we had a look at the Single Responsibility, Open/Closed, Liskov Substitution, and Interface Segregation principles.

Dependency Inversion is one of the last principles we are going to look at. The principle states that:

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

  2. Abstractions should not depend on details. Details should depend on abstractions.

Let’s get started with some code that violates that principle.

Say you are working as part of a software team. We need to implement a project. For now, the software team consists of:

A BackEnd Developer

package com.gkatzioura.solid.di;

public class BackEndDeveloper {

    public void writeJava() {
    }
}


And a FrontEnd developer:

package com.gkatzioura.solid.di;

public class FrontEndDeveloper {

    public void writeJavascript() {
    }

}


And our project uses both throughout the development process:

package com.gkatzioura.solid.di;

public class Project {

    private BackEndDeveloper backEndDeveloper = new BackEndDeveloper();
    private FrontEndDeveloper frontEndDeveloper = new FrontEndDeveloper();

    public void implement() {

        backEndDeveloper.writeJava();
        frontEndDeveloper.writeJavascript();
    }

}


So as we can see, the Project class is a high-level module, and it depends on low-level modules such as BackEndDeveloper and FrontEndDeveloper. We are actually violating the first part of the dependency inversion principle.

Also, by inspecting the implement function of Project.class, we realize that the methods writeJava and writeJavascript are methods bound to the corresponding classes. Regarding the project scope, those are details since, in both cases, they are forms of development. Thus, the second part of the dependency inversion principle is violated.

In order to tackle this problem, we shall implement an interface called the Developer interface:

package com.gkatzioura.solid.di;

public interface Developer {

    void develop();
}


Therefore, we introduce an abstraction.

The BackEndDeveloper shall be refactored to:

package com.gkatzioura.solid.di;

public class BackEndDeveloper implements Developer {

    @Override
    public void develop() {
        writeJava();
    }

    private void writeJava() {
    }

}


And the FrontEndDeveloper shall be refactored to:

package com.gkatzioura.solid.di;

public class FrontEndDeveloper implements Developer {

    @Override
    public void develop() {
        writeJavascript();
    }

    public void writeJavascript() {
    }

}


The next step, in order to tackle the violation of the first part, would be to refactor the Project class so that it will not depend on the FrontEndDeveloper and the BackendDeveloper classes.

package com.gkatzioura.solid.di;

import java.util.List;

public class Project {

    private List<Developer> developers;

    public Project(List<Developer> developers) {

        this.developers = developers;
    }

    public void implement() {

        developers.forEach(d->d.develop());
    }

}


The outcome is that the Project class does not depend on lower level modules, but rather abstractions. Also, low-level modules and their details depend on abstractions.

You can find the source code on GitHub.

Dependency inversion principle Dependency

Published at DZone with permission of Emmanouil Gkatziouras, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • AWS, Azure, and GCP: Find the Right Platform
  • Get Started With Kafka and Docker in 20 Minutes
  • Data Science: Scenario-Based Interview Questions
  • Debugging a Wordle Bug

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo