The Dependency Inversion Principle (DIP) states that:

• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

In simpler terms... High-level classes (those that contain the business logic) should not depend on low-level classes (those that handle specific details like the database or sending emails). Both should depend on interfaces or abstract classes.

# Inversion, Abstractions, and Details?

The Dependency Inversion Principle aims to reduce coupling between high-level code (policies, decisions) and low-level code (details, implementations), leading to more flexible and maintainable systems.

# Why is it important?

# Symptoms of violation

We can identify when we are not respecting the Dependency Inversion Principle:

• High-level code is directly linked to specific low-level implementations.
• Changes in low-level implementation details affecting high-level code.
• Difficulty changing or swapping low-level components due to rigid dependencies.

Example

Let's imagine a notification system for an application.

public class NotificationService {
    private EmailService emailService;
    public NotificationService() {
        this.emailService = new EmailService(); // Direct coupling
    }
    public void sendNotification(User user, String message) {
        emailService.sendEmail(user, message);
    }
    }

public interface MessageService {
    void sendMessage(User user, String message);
    }
public class EmailService implements MessageService {
    sendMessage(User user, String message) {
        // Specific implementation for sending an email
    }
    }
public class NotificationService {
    private MessageService messageService;
    public NotificationService(MessageService service) {
        // Dependency on an abstraction
    }
    public void sendNotification(User user, String message) {
        messageService.sendMessage(user, message);
    }
    }