Dependency Injection (DI) is a fundamental design pattern in Java that promotes loose coupling and maintainability in applications. I’ve implemented these techniques across numerous enterprise projects, and they’ve consistently improved code quality and testability.

Constructor Injection is my preferred approach for mandatory dependencies. It ensures all required dependencies are available when an object is created and makes the dependencies explicit. Here’s how we can implement it:

public class OrderProcessor {
    private final PaymentGateway paymentGateway;
    private final OrderRepository orderRepository;
    private final NotificationService notificationService;

    public OrderProcessor(PaymentGateway paymentGateway, 
                         OrderRepository orderRepository,
                         NotificationService notificationService) {
        this.paymentGateway = paymentGateway;
        this.orderRepository = orderRepository;
        this.notificationService = notificationService;
    }
}

Field injection, while convenient, should be used sparingly. I typically reserve it for optional dependencies or testing scenarios. The main advantage is its simplicity, but it can hide dependencies and make testing more challenging:

public class UserManager {
    @Inject
    private UserRepository userRepository;
    
    @Inject
    @SecurityLevel("HIGH")
    private EncryptionService encryptionService;
}

Method injection becomes particularly useful when we need to inject dependencies based on runtime conditions. I’ve used this approach when dealing with plugin-based architectures:

public class DocumentProcessor {
    private FormatConverter converter;
    
    @Inject
    public void setConverter(@DocumentType("PDF") FormatConverter converter) {
        this.converter = converter;
    }
}

Provider injection offers lazy loading and the ability to retrieve multiple instances. This technique has saved me considerable resources in high-load applications:

public class CacheManager {
    @Inject
    private Provider<DatabaseConnection> connectionProvider;
    
    public void refreshCache() {
        DatabaseConnection connection = connectionProvider.get();
        connection.executeQuery("REFRESH_CACHE");
    }
}

Custom scopes give precise control over object lifecycles. I implemented this pattern in a web application to manage user sessions:

@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface UserSession {}

public class UserSessionContext implements Context {
    private final Map<String, Object> sessionObjects = new ConcurrentHashMap<>();
    
    public <T> T get(Contextual<T> contextual) {
        String sessionId = getCurrentSessionId();
        return (T) sessionObjects.computeIfAbsent(sessionId,
            key -> contextual.create(this));
    }
}

Factory injection provides flexibility in object creation. This pattern is particularly valuable when dealing with multiple implementations:

public class PaymentServiceFactory {
    @Produces
    public PaymentProcessor createProcessor(Configuration config) {
        return switch (config.getPaymentProvider()) {
            case "VISA" -> new VisaProcessor();
            case "MASTERCARD" -> new MastercardProcessor();
            case "PAYPAL" -> new PayPalProcessor();
            default -> throw new UnsupportedOperationException();
        };
    }
}

Interceptors add cross-cutting concerns cleanly. I’ve used them extensively for logging, security, and transaction management:

@Interceptor
@Logged
public class LoggingInterceptor {
    @Inject
    private Logger logger;
    
    @AroundInvoke
    public Object log(InvocationContext context) throws Exception {
        logger.info("Entering: " + context.getMethod().getName());
        try {
            return context.proceed();
        } finally {
            logger.info("Exiting: " + context.getMethod().getName());
        }
    }
}

Qualifiers help distinguish between similar dependencies. They’re invaluable when working with multiple implementations of the same interface:

@Qualifier
@Retention(RetentionPolicy.RUNTIME)
public @interface PaymentType {
    String value();
}

@PaymentType("CREDIT")
public class CreditCardProcessor implements PaymentProcessor {
    // Implementation
}

@PaymentType("DEBIT")
public class DebitCardProcessor implements PaymentProcessor {
    // Implementation
}

Circular dependencies should be avoided, but when necessary, they can be resolved using method injection or providers:

public class ServiceA {
    @Inject
    private Provider<ServiceB> serviceBProvider;
    
    public void processA() {
        serviceBProvider.get().processB();
    }
}

public class ServiceB {
    @Inject
    private Provider<ServiceA> serviceAProvider;
    
    public void processB() {
        serviceAProvider.get().processA();
    }
}

Testing becomes straightforward with dependency injection. We can easily mock dependencies:

public class OrderServiceTest {
    @Mock
    private PaymentGateway paymentGateway;
    @Mock
    private OrderRepository orderRepository;
    
    private OrderService orderService;
    
    @Before
    public void setup() {
        orderService = new OrderService(paymentGateway, orderRepository);
    }
    
    @Test
    public void testOrderProcessing() {
        // Test implementation
    }
}

These techniques form a comprehensive toolkit for managing dependencies in Java applications. The key is choosing the right technique for each specific use case. Constructor injection for mandatory dependencies, method injection for optional ones, providers for lazy loading, and interceptors for cross-cutting concerns.

Remember to maintain a balance between flexibility and complexity. Not every scenario requires advanced DI techniques. Sometimes, simple constructor injection is sufficient. The goal is to create maintainable, testable code that’s easy to understand and modify.

In my experience, mastering these patterns has led to more robust and flexible applications. They provide the foundation for building scalable enterprise systems while keeping the code clean and manageable.