DIP vs DI: Understanding the Difference in Java

When we talk about clean code, testability, and maintainable architecture in Java applications, two terms often appear together: DIP and DI.

They sound similar, and they are closely related, but they are not the same thing.

DIP is a design principle. DI is a technique used to apply that principle.

Understanding this difference helps us design code that is easier to test, easier to change, and less tightly coupled to specific technologies.

What is DIP?

DIP stands for Dependency Inversion Principle.

It is one of the five SOLID principles.

The main idea is:

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

In simpler words:

Business logic should not directly depend on concrete technical details such as MySQL, PostgreSQL, file storage, or external APIs.
Instead, it should depend on interfaces or abstractions.

Let’s look at a simple example.

class OrderService {
    private MySQLOrderRepository repository = new MySQLOrderRepository();

    public void placeOrder(Order order) {
        repository.save(order);
    }
}

At first glance, this code looks simple.

But there is a problem.

OrderService is a high-level module. It contains business logic related to placing orders.

MySQLOrderRepository is a low-level module. It contains technical details about how orders are stored in MySQL.

The problem is that OrderService directly depends on MySQLOrderRepository.

That means the business logic is tightly connected to a specific database implementation.

If we later want to change MySQL to PostgreSQL, use a mock repository for testing, or store orders through an external service, we may need to modify OrderService.

That is the kind of dependency DIP tries to avoid.

Applying DIP with an Abstraction

A better design is to introduce an interface.

public interface OrderRepository {
    void save(Order order);
}

Now the MySQL implementation can implement this interface.

public class MySQLOrderRepository implements OrderRepository {

    @Override
    public void save(Order order) {
        // Save order to MySQL
    }
}

Then OrderService depends on the interface, not the concrete class.

public class OrderService {

    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }

    public void placeOrder(Order order) {
        repository.save(order);
    }
}

Now OrderService does not know whether the actual repository uses MySQL, PostgreSQL, MongoDB, or a test implementation.

It only knows the contract:

OrderRepository

This is the key idea of DIP.

The business logic depends on an abstraction, and the infrastructure code implements that abstraction.

What is DI?

DI stands for Dependency Injection.

DI is a way to provide dependencies from the outside instead of creating them inside the class.

Without DI, a class creates its own dependency.

public class OrderService {

    private final OrderRepository repository = new MySQLOrderRepository();
}

With DI, the dependency is passed from outside.

public class OrderService {

    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
}

This is constructor injection.

The object that uses the dependency does not create it. It simply receives it.

This makes the class easier to test and easier to reuse.

DIP vs DI

DIP and DI are related, but they solve different parts of the problem.

Concept	Meaning
DIP	A design principle about the direction of dependencies
DI	A technique for providing dependencies from outside

DIP says:

Depend on abstractions, not concrete implementations.

DI says:

Do not create dependencies inside the class. Provide them from outside.

So we can summarize the difference like this:

DIP defines how dependencies should be designed.
DI defines how dependencies are supplied.

Why the Word “Inversion”?

The word inversion can be confusing.

In a simple design, the dependency often looks like this:

OrderService -> MySQLOrderRepository

The high-level business logic depends directly on the low-level database implementation.

After applying DIP, the dependency looks like this:

OrderService -> OrderRepository
MySQLOrderRepository -> OrderRepository

Now both the service and the implementation depend on the abstraction.

The direction has changed.

Instead of the business logic depending on infrastructure details, the infrastructure details depend on the abstraction defined by the business logic layer.

That is why it is called Dependency Inversion.

Using DIP and DI in Spring

In Spring applications, this pattern is very common.

@Service
public class OrderService {

    private final OrderRepository orderRepository;

    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void placeOrder(Order order) {
        orderRepository.save(order);
    }
}

And the repository implementation can look like this:

@Repository
public class JpaOrderRepository implements OrderRepository {

    @Override
    public void save(Order order) {
        // Save order using JPA
    }
}

OrderService depends on OrderRepository, not JpaOrderRepository.

Spring creates the actual implementation object and injects it into OrderService.

In this case:

• DIP is applied because the service depends on an abstraction.
• DI is used because Spring provides the dependency from outside.

Spring makes DI convenient, but DI itself is not limited to Spring.

We can also do manual dependency injection.

OrderRepository repository = new MySQLOrderRepository();
OrderService orderService = new OrderService(repository);

This is still DI because the dependency is passed from outside.

DI Without DIP

One common misunderstanding is that using DI automatically means we are following DIP.

That is not always true.

Look at this example:

public class OrderService {

    private final MySQLOrderRepository repository;

    public OrderService(MySQLOrderRepository repository) {
        this.repository = repository;
    }
}

This code uses constructor injection, so it is using DI.

However, OrderService still depends on the concrete class MySQLOrderRepository.

So DI is used, but DIP is not fully applied.

This is an important distinction.

DI is only a technique. To follow DIP properly, the dependency should usually be an abstraction.

A better version is:

public class OrderService {

    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
}

Now the service depends on the interface.

Why This Matters

DIP and DI are not just theoretical ideas. They have practical benefits in real projects.

Easier Testing

When a service depends on an interface, we can inject a fake or mock implementation during testing.

public class FakeOrderRepository implements OrderRepository {

    @Override
    public void save(Order order) {
        // Fake save logic for testing
    }
}

Then we can test OrderService without connecting to a real database.

OrderRepository fakeRepository = new FakeOrderRepository();
OrderService orderService = new OrderService(fakeRepository);

This makes unit tests faster and more stable.

Easier Replacement

If the application starts with MySQL and later moves to PostgreSQL, we can add a new implementation.

public class PostgreSQLOrderRepository implements OrderRepository {

    @Override
    public void save(Order order) {
        // Save order to PostgreSQL
    }
}

The OrderService does not need to change.

It still depends on the same interface.

private final OrderRepository repository;

This reduces the impact of infrastructure changes.

Lower Coupling

Without DIP, business logic is tightly coupled to technical details.

OrderService -> MySQLOrderRepository

With DIP, the service depends only on a contract.

OrderService -> OrderRepository

Lower coupling makes the system easier to maintain as it grows.

This becomes especially important in large applications where database access, external APIs, message queues, and third-party services can change over time.

A Simple Way to Remember

The easiest way to remember the difference is:

DIP is the principle.
DI is the mechanism.

Or, more clearly:

DIP defines the direction of dependencies.
DI provides those dependencies from outside.

DIP helps us decide what our code should depend on.

DI helps us decide how those dependencies are provided.

When used together, they make Java applications cleaner, more flexible, and easier to test.

Final Thoughts

DIP and DI are often used together, but they are not the same concept.

DIP is about design. It tells us to keep business logic independent from low-level implementation details.

DI is about object creation and wiring. It helps us provide dependencies from the outside instead of creating them directly inside a class.

In a well-designed Java application, services usually depend on interfaces, and concrete implementations are injected through constructors or a DI framework like Spring.

This simple separation can make a big difference in long-term maintainability.