Dependency Injection vs Constructor Parameters

Avoiding the Overuse of DI in Large Software Systems

In large software systems, Dependency Injection (DI) is often promoted as a solution for managing dependencies, particularly by frameworks like Spring. However, DI can easily be overused, leading to unnecessary complexity and making logic flows harder to follow. The "magic" introduced by DI, while sometimes useful, can obscure how objects are instantiated and wired together, complicating debugging and maintenance.

Instead, it’s better to default to passing dependencies explicitly through constructor parameters, only using DI when it’s absolutely necessary. Let’s start with a basic example to illustrate the two approaches.

Example: Constructor Parameters vs Dependency Injection

Consider a class OrderService that depends on two other components: PaymentService and InventoryService. Here's how you would handle this with both approaches.

Constructor-Based Instantiation

In this approach, dependencies are passed directly to the OrderService constructor, making the wiring explicit.

public class OrderService {
    private final PaymentService paymentService;
    private final InventoryService inventoryService;

    // Constructor accepting dependencies explicitly
    public OrderService(PaymentService paymentService, InventoryService inventoryService) {
        this.paymentService = paymentService;
        this.inventoryService = inventoryService;
    }

    public void placeOrder(Order order) {
        if (inventoryService.isInStock(order)) {
            paymentService.processPayment(order.getPaymentDetails());
            // Continue order processing...
        }
    }
}

// Instantiating dependencies manually
PaymentService paymentService = new PaymentService();
InventoryService inventoryService = new InventoryService();

// Manually passing dependencies via the constructor
OrderService orderService = new OrderService(paymentService, inventoryService);

// Now orderService can be used to place orders
orderService.placeOrder(order);

Dependency Injection (Spring Framework)

In this case, a framework like Spring is used to automatically inject the dependencies. This hides the wiring logic behind annotations and the DI framework.

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class OrderService {
    private final PaymentService paymentService;
    private final InventoryService inventoryService;

    // Dependencies are injected by Spring at runtime
    @Autowired
    public OrderService(PaymentService paymentService, InventoryService inventoryService) {
        this.paymentService = paymentService;
        this.inventoryService = inventoryService;
    }

    public void placeOrder(Order order) {
        if (inventoryService.isInStock(order)) {
            paymentService.processPayment(order.getPaymentDetails());
            // Continue order processing...
        }
    }
}

// Spring automatically injects dependencies based on configuration
@Service
public class PaymentService {
    // Payment logic...
}

@Service
public class InventoryService {
    // Inventory logic...
}

// No need to manually instantiate or pass dependencies, Spring does it
// Assuming this is part of a Spring-managed application, like a controller:
@Autowired
private OrderService orderService;

orderService.placeOrder(order);

Let's break down the key elements:

Annotations: The code uses Spring annotations like @Service and @Autowired, which are core to Spring's dependency injection mechanism.
Dependency Injection: The OrderService constructor is annotated with @Autowired, allowing Spring to inject the required dependencies (PaymentService and InventoryService) at runtime.
Service Layer: The classes are annotated with @Service, indicating that they are part of the service layer in a Spring application.
Loose Coupling: The services are designed with interfaces, promoting loose coupling, which is a key principle in Spring applications.
Automatic Wiring: The last part of the code shows how a Spring-managed bean (like a controller) would autowire and use the OrderService without manually instantiating it.

The two examples are similar but the second one requires more effort to understand the relationships among classes.

Constructor Parameters: The Preferred Approach for Most Cases

Constructor parameters provide clarity. They make object dependencies explicit and easy to follow, without relying on an external framework or DI container. This approach should be your default for most dependencies, especially when dealing with simple objects or entities that have a clear lifecycle.

1. Simple or Immutable Objects

When to use: Pass simple, immutable, or value objects directly through the constructor.
Examples: DTOs, primitives, or domain objects.
Why: These objects are straightforward and don’t need the complexity of DI. Passing them directly makes the code transparent, without hidden logic.

2. Short-Lived or Local-Scope Objects

When to use: For objects that are short-lived or only relevant to a specific operation within the class.
Examples: Temporary calculations, single-use helper objects, or configurations tied to a particular task.
Why: These objects are typically not shared or reused across the system, making DI overkill. Passing them via the constructor is simpler and makes it obvious where they are needed.

3. Domain Logic Entities

When to use: For domain-specific objects central to your business logic.
Examples: Core entities or value objects in a domain-driven design (DDD) system.
Why: Domain objects are integral to your business logic, and their lifecycle is usually well-defined. Using the constructor keeps these dependencies explicit, ensuring that the logic remains clear.

4. Complex Object Construction via Factory or Builder Pattern

When to use: For objects with complex construction logic, use a factory or builder pattern instead of DI.
Examples: Objects that require multiple dependencies or conditional logic during instantiation.
Why: DI can add unnecessary "magic" to the creation of complex objects, making the construction harder to follow. A factory or builder makes the process clear, without relying on external injection.

Dependency Injection: When It’s Justified

While DI can add complexity, it can also be useful in certain scenarios, particularly when dealing with shared services or external resources. Here’s when it might be worth the trade-off:

1. Shared Services

When to use: For services used across multiple parts of the application.
Examples: Logging services, database connections.
Why: Shared services often need to be managed centrally, and DI can simplify this by handling lifecycles and reuse.

2. Mockable Dependencies for Testing

When to use: For dependencies that need to be mocked or stubbed during testing.
Examples: External APIs, repositories.
Why: DI makes it easier to swap real implementations for test doubles, improving testability.

3. Environment-Specific Configuration

When to use: For configuration values that change based on the environment.
Examples: API keys, feature flags.
Why: Injecting these values allows flexibility across environments, but be cautious of how this can obscure logic.

4. Complex Lifecycle Management

When to use: For objects with complex lifecycles, such as those managing state or connections.
Examples: Session managers, transaction handlers.
Why: DI can simplify managing lifecycles like singleton or scoped objects, but ensure it doesn’t introduce unnecessary complexity.

5. Avoiding Constructor Overload

When to use: When a class has too many dependencies to reasonably pass through a constructor.
Examples: Large services that depend on multiple collaborators.
Why: If a constructor has too many parameters, it can become unwieldy. DI can reduce this clutter, but a high number of dependencies may indicate a design problem that should be addressed first.

Summary

This table provides a concise comparison between using Constructor Parameters and Dependency Injection, based on when each approach is preferred. It summarizes the scenarios where Constructor Parameters are ideal for maintaining simplicity and transparency versus when Dependency Injection is justified, particularly for complex, flexible, and testable system requirements.

Criteria	Constructor Parameters: The Preferred Approach for Most Cases	Dependency Injection: When It’s Justified
Suitability	Best for simple, core objects and domain logic entities	Appropriate for shared services or when testability is crucial
Complexity	Lower complexity, dependencies are transparent	Higher complexity due to external framework involvement
Control and Transparency	Dependencies are explicit and easy to understand	Hidden dependencies can lead to obscured logic flow
Flexibility and Lifecycle	Less flexible, manual lifecycle management	High flexibility and automated lifecycle handling
Best Practices	Prefer when few dependencies are involved, simplicity is key	Use DI for managing services and decoupling classes

Conclusion: DI Should Be the Exception, Not the Rule

While DI can offer certain advantages, it should be used sparingly and only when its benefits are crystal clear. In many cases, constructor parameters provide a simpler, more transparent way to handle dependencies, keeping your logic clean and easy to follow.

Before turning to DI, always ask whether the flexibility it offers is worth the added complexity. By favoring explicit dependencies through constructors and using DI only when absolutely necessary, you’ll keep your codebase more maintainable and easier to debug in the long run.