Lowering Coupling with Dependency Injection in Java

What is Dependency Injection?

Dependency Injection (DI) is a design pattern used to implement Inversion of Control (IoC). It allows the creation of dependent objects to occur outside of a class and provides those dependencies to the class in various ways. In simple terms, instead of a class creating its own dependencies, the dependencies are “injected” into it by an external entity (often a DI framework).

This pattern is fundamental to building loosely coupled systems, which are easier to test, maintain, and extend.

The Problem: Tight Coupling

Let’s consider a NotificationService that sends emails. Without DI, the service might create its own EmailClient instance directly.

Tightly Coupled Code:

// The dependency
class EmailClient {
    public void send(String message) {
        System.out.println("Sending email: " + message);
    }
}

// The dependent class
class NotificationService {
    private EmailClient client;

    public NotificationService() {
        // The service is creating its own dependency. This is a problem!
        this.client = new EmailClient(); 
    }

    public void sendNotification(String message) {
        this.client.send(message);
    }
}

This design has several problems:

1. Inflexible: If we want to switch to sending SMS messages instead of emails, we have to change the NotificationService class itself.
2. Hard to Test: When testing NotificationService, we cannot easily replace the real EmailClient with a mock or fake version. The test would actually try to send an email.
3. Violates Single Responsibility Principle: NotificationService is responsible for both sending notifications and managing the lifecycle of EmailClient.

The Solution: Dependency Injection

With DI, we “invert the control.” The responsibility of creating the EmailClient is moved outside the NotificationService.

First, we should depend on an abstraction (interface) rather than a concrete class.

// 1. Create an interface (the abstraction)
interface MessageClient {
    void send(String message);
}

// 2. Create concrete implementations
class EmailClient implements MessageClient {
    @Override
    public void send(String message) {
        System.out.println("Sending email: " + message);
    }
}

class SmsClient implements MessageClient {
    @Override
    public void send(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

Now, we can inject the dependency into NotificationService.

Types of Dependency Injection

There are three common types of DI:

1. Constructor Injection

The dependencies are provided through the class constructor. This is the most common and recommended approach.

class NotificationService {
    private final MessageClient client; // Depend on the interface

    // The dependency is injected via the constructor
    public NotificationService(MessageClient client) {
        this.client = client;
    }

    public void sendNotification(String message) {
        this.client.send(message);
    }
}

// Usage:
MessageClient emailClient = new EmailClient();
NotificationService notificationService = new NotificationService(emailClient);
notificationService.sendNotification("Hello via Email!");

// To switch to SMS, just inject a different implementation:
MessageClient smsClient = new SmsClient();
NotificationService smsNotificationService = new NotificationService(smsClient);
smsNotificationService.sendNotification("Hello via SMS!");

Benefits: Dependencies are clearly stated and can be made final, ensuring they are not changed after instantiation.

2. Setter (or Method) Injection

The dependencies are provided through public setter methods.

class NotificationService {
    private MessageClient client;

    public void setClient(MessageClient client) {
        this.client = client;
    }
    // ...
}

Benefits: Useful for optional dependencies or when you need to change the dependency after the object has been created.

3. Field Injection

Dependencies are injected directly into the fields of a class. This is common in frameworks like Spring but is often considered less ideal because it hides the dependencies and makes testing harder without a DI container.

Spring Framework Example:

@Component // Tells Spring to manage this class as a bean
class NotificationService {
    @Autowired // Tells Spring to inject the dependency here
    private MessageClient client;

    // ...
}

Dependency Injection Frameworks (Spring, Guice)

Manually creating and injecting dependencies (as shown in the constructor injection example) can become tedious in large applications. DI frameworks automate this process.

• Spring: One of the most popular Java frameworks. It has a powerful DI container that manages the lifecycle of objects (called “beans”) and injects them where needed using annotations like @Autowired.
• Google Guice: A lightweight DI framework that also uses annotations to wire dependencies together.

These frameworks use configuration (XML or annotations) to understand which implementation to inject for a given interface.

Key Takeaway

Dependency Injection is a powerful pattern for building loosely coupled and highly testable applications. By letting an external entity provide dependencies to your classes, you make your code more flexible, modular, and maintainable. While you can implement DI manually, using a framework like Spring or Guice is the standard approach for modern Java applications.

Professional Depth Check

For Lowering Coupling with Dependency Injection in Java, the practical standard is not whether the reader can repeat one instruction once. Treat the topic as a reproducible debugging procedure: verify JDK version, build tool configuration, classpath or module path, and runtime stack trace before drawing a conclusion. The result should be written as a small decision record, because future readers need to know which fact was observed, which assumption was used, and which condition would change the answer.

Evidence That Makes the Guidance Reliable

Use objective evidence before changing a workflow. Good evidence includes java -version, javac -version, Maven or Gradle output, and the smallest failing class. If two pieces of evidence conflict, keep the conflict visible instead of smoothing it over. For example, a successful quick fix is still weak evidence if the same input, account, dependency, or device state has not been tested again. A durable article should help the reader distinguish a confirmed fix from a plausible fix.

Review Table

Review Item	What To Confirm	Why It Matters
Scope	The exact case covered by this article	Prevents over-applying the advice
Baseline	The state before any change	Makes rollback and comparison possible
Change	The smallest action taken	Reduces hidden side effects
Result	The observed output after the change	Separates evidence from expectation
Recheck	When to revisit the conclusion	Keeps the post accurate over time

Edge Cases and Failure Modes

The main risks are fixing the symptom while leaving the root cause, and mixing unrelated changes into the same test. When the situation involves production data, personal information, money, health, legal rights, or security recovery, the conservative path is to stop and collect evidence before applying a broad fix. The same title can describe very different cases, so the reader should compare their environment with the assumptions in the post before copying commands or decisions.

Related Reading

Continue with these related posts from the same topic area.

• How to Fix “SSL: CERTIFICATE_VERIFY_FAILED” Error in Python on Windows
• How to Fix “Permission denied (publickey)” Error with Git on Windows