Dependency Injection (DI)

// Constructor injection — RECOMMENDED for all mandatory dependencies:
@Service
public class UserService {

    private final UserRepository userRepository;
    private final EmailService emailService;
    private final PasswordEncoder passwordEncoder;

    // @Autowired is optional when there's exactly one constructor (Spring 4.3+):
    public UserService(UserRepository userRepository,
                       EmailService emailService,
                       PasswordEncoder passwordEncoder) {
        this.userRepository = userRepository;
        this.emailService = emailService;
        this.passwordEncoder = passwordEncoder;
    }
}

// Why constructor injection wins:

// 1. Fields can be FINAL — dependencies are guaranteed to be set:
private final UserRepository userRepository;
// NullPointerException is impossible — the field is set in the constructor
// or the constructor throws before the object is even created

// 2. TESTABLE WITHOUT SPRING — just call the constructor directly:
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
    @Mock UserRepository userRepository;
    @Mock EmailService emailService;
    @Mock PasswordEncoder passwordEncoder;
    @InjectMocks UserService userService;

    // Or manually:
    UserService service = new UserService(
        mock(UserRepository.class),
        mock(EmailService.class),
        mock(PasswordEncoder.class)
    );
    // No Spring context needed — pure Java unit test
}

// 3. EXPLICIT DEPENDENCIES — all deps visible in the constructor signature:
// A constructor with 8 parameters is a warning sign — class does too much
// This visibility makes over-injected classes obvious (unlike @Autowired fields)

// 4. CIRCULAR DEPENDENCY DETECTION at startup:
// A → B → A will throw BeanCurrentlyInCreationException immediately
// With field injection, circular deps silently create proxy objects

// Lombok @RequiredArgsConstructor — generates constructor automatically:
@Service
@RequiredArgsConstructor   // generates constructor for all final fields
public class UserService {
    private final UserRepository userRepository;
    private final EmailService emailService;
    private final PasswordEncoder passwordEncoder;
    // Lombok generates the constructor — no boilerplate
}

// Setter injection — for OPTIONAL dependencies:
@Service
public class NotificationService {

    private EmailService emailService;
    private SmsService smsService;
    private MetricsCollector metricsCollector;

    // required=false — bean is not created if EmailService doesn't exist:
    @Autowired(required = false)
    public void setEmailService(EmailService emailService) {
        this.emailService = emailService;
    }

    @Autowired(required = false)
    public void setSmsService(SmsService smsService) {
        this.smsService = smsService;
    }

    @Autowired(required = false)
    public void setMetricsCollector(MetricsCollector metricsCollector) {
        this.metricsCollector = metricsCollector;
    }

    public void notify(String message) {
        // Gracefully handle absent optional dependencies:
        if (emailService != null) {
            emailService.send(message);
        }
        if (smsService != null) {
            smsService.send(message);
        }
        if (metricsCollector != null) {
            metricsCollector.recordNotification();
        }
    }
}

// Setter injection trade-offs:
// PROS:
// - Clearly marks a dependency as optional
// - Can be re-injected after construction (useful in testing)
// - Allows circular dependency resolution (Spring uses setter injection
//   internally to break circular dependency cycles)

// CONS:
// - Fields cannot be final — dependency might be null
// - Object can be in an incomplete state between construction and setter call
// - Less visible than constructor parameters
// - Requires null checks throughout the class

// When to use setter injection:
// - The dependency is genuinely optional (class works without it)
// - You're integrating with a framework that requires a no-arg constructor
// - You need to reconfigure dependencies after startup (rare)

// Field injection — @Autowired directly on the field:
@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;   // cannot be final

    @Autowired
    private CategoryService categoryService;

    @Autowired
    private PricingService pricingService;
}

// Why field injection is problematic:

// PROBLEM 1 — Cannot be final:
@Autowired
private ProductRepository productRepository;   // no final — could be null

// PROBLEM 2 — Impossible to test without Spring context:
// To test ProductService, you MUST start a Spring context OR use reflection:
class ProductServiceTest {
    @Autowired ProductService service;  // needs @SpringBootTest or @ExtendWith(SpringExtension)
    // Heavy, slow, loads entire context just to test one method

    // The only alternative is ugly reflection:
    ProductService service = new ProductService();
    ReflectionTestUtils.setField(service, "productRepository", mockRepo);
    // This is fragile and hides the dependency relationship
}

// PROBLEM 3 — Hidden dependencies:
// new ProductService() — looks fine, but it's missing its dependencies
// No indication at construction time that three injections are required
// Fails at runtime, not at compile time

// PROBLEM 4 — Encourages too many dependencies:
// It's easy to keep adding @Autowired fields without noticing
// The class grows without the friction that constructor parameters create
// A constructor with 10 parameters is obviously a problem
// Ten @Autowired fields are easy to ignore

// When field injection is acceptable:
// - Quick prototypes and demos (not production code)
// - Test classes themselves (@Autowired in @SpringBootTest test classes is fine)
// - Legacy codebases where refactoring isn't feasible

// In @SpringBootTest test classes — field injection is fine:
@SpringBootTest
class IntegrationTest {
    @Autowired UserService userService;   // acceptable in tests
    @Autowired UserRepository userRepository;
}

// Basic @Autowired — injects by type:
@Autowired
private PaymentService paymentService;
// Spring finds the single bean that implements PaymentService and injects it

// Multiple implementations — ambiguity:
@Component
public class StripePaymentService implements PaymentService { }

@Component
public class PaypalPaymentService implements PaymentService { }

// Spring finds TWO beans of type PaymentService — throws:
// NoUniqueBeanDefinitionException: expected single matching bean but found 2

// FIX 1 — @Primary: mark one as the default:
@Component
@Primary
public class StripePaymentService implements PaymentService { }

@Component
public class PaypalPaymentService implements PaymentService { }

// Now @Autowired injects StripePaymentService by default

// FIX 2 — @Qualifier: specify which bean by name:
@Autowired
@Qualifier("stripePaymentService")   // bean name defaults to class name (camelCase)
private PaymentService paymentService;

// Or name the bean explicitly:
@Component("stripe")
public class StripePaymentService implements PaymentService { }

@Component("paypal")
public class PaypalPaymentService implements PaymentService { }

@Autowired
@Qualifier("stripe")
private PaymentService paymentService;

// FIX 3 — Inject ALL implementations as a collection:
@Autowired
private List<PaymentService> paymentServices;
// Contains both StripePaymentService and PaypalPaymentService

@Autowired
private Map<String, PaymentService> paymentServiceMap;
// {"stripePaymentService": StripePaymentService, "paypalPaymentService": PaypalPaymentService}

// FIX 4 — @Autowired with Optional:
@Autowired
private Optional<MetricsCollector> metricsCollector;
// Empty Optional if no MetricsCollector bean exists — no exception

// @Value — inject individual properties:
@Service
public class JwtService {

    @Value("${app.jwt.secret}")
    private String secret;

    @Value("${app.jwt.expiration:3600}")   // default value after colon
    private long expiration;

    @Value("${app.jwt.issuer:https://myapp.com}")
    private String issuer;

    // SpEL expressions in @Value:
    @Value("#{systemProperties['java.home']}")
    private String javaHome;

    @Value("#{'${app.allowed.origins}'.split(',')}")
    private List<String> allowedOrigins;

    @Value("#{T(java.lang.Math).PI}")
    private double pi;
}

// @ConfigurationProperties — bind a group of properties to a class:
@ConfigurationProperties(prefix = "app.mail")
@Component
@Validated   // enables Bean Validation on the properties
public class MailProperties {

    @NotBlank
    private String host;

    @Min(1) @Max(65535)
    private int port = 587;

    @NotBlank
    private String username;

    private String password;

    private boolean ssl = true;

    @NotEmpty
    private List<String> recipients;

    // getters and setters (or use @Data from Lombok)
}

// application.properties:
// app.mail.host=smtp.gmail.com
// app.mail.port=465
// app.mail.username=myapp@gmail.com
// app.mail.password=${MAIL_PASSWORD}
// app.mail.ssl=true
// app.mail.recipients=admin@myapp.com,ops@myapp.com

// Inject and use:
@Service
public class EmailService {
    private final MailProperties mail;

    public EmailService(MailProperties mail) {
        this.mail = mail;
    }

    public void send(String to, String subject, String body) {
        // use mail.getHost(), mail.getPort(), etc.
    }
}

// Record-based @ConfigurationProperties (Spring Boot 2.6+, Java 16+):
@ConfigurationProperties(prefix = "app.jwt")
public record JwtProperties(
    @NotBlank String secret,
    @Min(300) long expiration,
    String issuer
) { }

// Circular dependency — Spring detects and throws at startup:
@Service
public class ServiceA {
    private final ServiceB serviceB;
    public ServiceA(ServiceB serviceB) { this.serviceB = serviceB; }
}

@Service
public class ServiceB {
    private final ServiceA serviceA;
    public ServiceB(ServiceA serviceA) { this.serviceA = serviceA; }
}
// BeanCurrentlyInCreationException: A depends on B which depends on A

// The RIGHT fix — redesign to remove the circular dependency:

// Option 1 — Extract the shared logic into a third service:
@Service
public class SharedService {
    public void sharedOperation() { }
}

@Service
public class ServiceA {
    private final SharedService sharedService;
    // ServiceA no longer needs ServiceB
}

@Service
public class ServiceB {
    private final SharedService sharedService;
    // ServiceB no longer needs ServiceA
}

// Option 2 — Use events to decouple:
@Service
public class ServiceA {
    private final ApplicationEventPublisher eventPublisher;

    public void doWork() {
        // Instead of calling ServiceB directly, publish an event:
        eventPublisher.publishEvent(new WorkCompletedEvent(this));
    }
}

@Service
public class ServiceB {
    @EventListener
    public void onWorkCompleted(WorkCompletedEvent event) {
        // React to the event — no direct dependency on ServiceA
    }
}

// Option 3 — @Lazy (workaround, not ideal):
@Service
public class ServiceA {
    private final ServiceB serviceB;
    public ServiceA(@Lazy ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}
// @Lazy injects a proxy — ServiceB is created on first use
// Hides the design problem rather than solving it — use sparingly

// SCOPE MISMATCH — common bug:
@Service  // singleton — lives for the entire application lifetime
public class OrderService {

    @Autowired
    private UserSession userSession;  // request-scoped — different per request
    // PROBLEM: OrderService is created once.
    // It holds a reference to the FIRST UserSession ever created.
    // Every request uses the same stale UserSession — WRONG.
}

// FIX 1 — Inject a scoped proxy instead of the bean directly:
@Component
@Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserSession {
    private String userId;
    private String token;
    // getters and setters
}

@Service
public class OrderService {
    @Autowired
    private UserSession userSession;
    // userSession is a proxy — each method call on it delegates to
    // the real UserSession for the CURRENT request. Works correctly.
}

// FIX 2 — Use ApplicationContext to look up the bean per request:
@Service
public class OrderService {
    private final ApplicationContext context;

    public OrderService(ApplicationContext context) {
        this.context = context;
    }

    public Order createOrder(OrderRequest request) {
        UserSession session = context.getBean(UserSession.class); // fresh per call
        // use session...
    }
}

// Scope summary:
// singleton   → one instance per ApplicationContext (default)
// prototype   → new instance every time it's requested
// request     → one instance per HTTP request (web only)
// session     → one instance per HTTP session (web only)
// application → one instance per ServletContext (web only)

// ── BEST PRACTICE 1: Always use constructor injection ────────────
// DO:
@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository repository;  // final — guaranteed non-null
    private final EmailService emailService;  // visible in constructor signature
}

// DON'T:
@Service
public class UserService {
    @Autowired private UserRepository repository;  // not final, hidden dependency
}

// ── BEST PRACTICE 2: Program to interfaces ────────────────────────
// DO:
@Service
public class OrderService {
    private final PaymentService paymentService;  // interface type
    // Inject StripePaymentService or PaypalPaymentService — OrderService doesn't care
}

// DON'T:
@Service
public class OrderService {
    private final StripePaymentService stripePaymentService;  // concrete class
    // Tightly coupled — can't switch payment providers without changing OrderService
}

// ── BEST PRACTICE 3: Keep constructor parameter count low ─────────
// More than 4-5 constructor parameters = class has too many responsibilities
// DO: Split into smaller, more focused services
// Single Responsibility Principle applies here

// ── BEST PRACTICE 4: Use @Primary and @Qualifier deliberately ─────
// @Primary: "this is the default implementation — used unless overridden"
// @Qualifier: "I specifically need this exact implementation"
// Avoid both: redesign so there's only one implementation per interface

// ── BEST PRACTICE 5: Use @ConfigurationProperties over @Value ─────
// DO:
@ConfigurationProperties(prefix = "app.stripe")
public class StripeProperties {
    private String apiKey;
    private String webhookSecret;
    private boolean testMode;
    // IDE auto-complete, type safety, validation — all work
}

// DON'T (for groups of related properties):
@Value("${app.stripe.api-key}") private String apiKey;
@Value("${app.stripe.webhook-secret}") private String webhookSecret;
@Value("${app.stripe.test-mode:false}") private boolean testMode;
// No auto-complete, no validation, scattered across the class

// ── BEST PRACTICE 6: Never use DI in utility/static classes ───────
// Static utility classes don't need Spring — don't add @Component
// If a utility needs Spring beans, make it a proper @Component itself