DI
3 WAYS

@Service
public class OrderService {

    private final PaymentService paymentService;
    // [읽기 단계] "paymentService 필드가 있고, final이다" 파악
    // [이 시점 Heap] 아직 OrderService 객체 없음, 필드도 없음

    public OrderService(PaymentService paymentService) {
    // ↑ [읽기 단계] "PaymentService 없이는 만들 수 없다"는 생성자 정보 파악
    //   스프링: "OrderService 만들려면 PaymentService Bean 먼저 있어야 함"
    //
    // [스프링 Bean 생성 단계 — 실제 실행]
    // Step 1: PaymentService Bean 이미 Heap에 있음 (0x1A2B)
    // Step 2: new OrderService(paymentServiceBean) 호출
    // Step 3: Stack에 생성자 프레임 push
    //         매개변수 paymentService = 0x1A2B (Stack 지역변수)
    // Step 4: Heap에 OrderService 객체 공간 확보 (0x3C4D)
    //         → paymentService 필드 공간 포함 (아직 null)

        this.paymentService = paymentService;
        // Step 5: this(0x3C4D)의 paymentService 필드 = Stack의 0x1A2B
        //         → Heap 0x3C4D 안의 필드가 Heap 0x1A2B를 가리킴
        //         → DI 완료!
        //         → final이라 이 순간 이후 절대 변경 불가 (컴파일러 보장)

    // Step 6: 생성자 프레임 pop → Stack 지역변수(0x1A2B 참조) 소멸
    //         단, Heap의 OrderService.paymentService 필드는 0x1A2B 그대로 유지
    }

    public void order() {
        // [요청 처리 시 — 매 호출마다]
        // Step 7: Stack에 order() 프레임 push
        paymentService.pay();
        // Step 8: this(현재 OrderService Bean 0x3C4D).paymentService = 0x1A2B
        //         → Heap의 PaymentService Bean.pay() 실행
        //         → Stack에 pay() 프레임 push → 실행 → pop
        // Step 9: order() 프레임 pop
    }
}

// ═══ 최종 Heap 상태 ═══════════════════════════════════════
// 0x1A2B: PaymentService Bean (서버 살아있는 한 유지)
// 0x3C4D: OrderService Bean
//         ↳ paymentService 필드 = 0x1A2B (영구 연결, 변경 불가)
// ══════════════════════════════════════════════════════════

@Service
public class OrderService {

    @Autowired
    // ↑ 스프링한테 "이 필드에 맞는 Bean 알아서 넣어줘" 표시
    private PaymentService paymentService;
    // ↑ final 없음 → 나중에 다른 값으로 바뀔 수 있음

    // 생성자가 없음 → 컴파일러가 기본 생성자 자동 추가:
    // public OrderService() { } ← 매개변수 없음

    // 스프링 실행 순서:
    // Step 1: new OrderService() → Heap에 객체 생성
    //         ↑ 이 시점에 paymentService = null (아직 아무것도 없음)
    //         ↑ "반쪽짜리 객체" 상태!
    // Step 2: 생성 완료 후, 스프링이 리플렉션으로 필드에 강제 주입
    //         Reflection: private 필드도 강제로 접근 가능한 Java 기능
    //         orderServiceBean.paymentService = paymentServiceBean; (강제 할당)
    //         이제서야 paymentService = 0x1A2B

    public void order() {
        paymentService.pay();
        // 만약 Step 2가 일어나기 전에 order()가 호출되면?
        // paymentService = null → NullPointerException!
        // (스프링 정상 환경에서는 거의 안 일어나지만 테스트 환경에서는 발생)
    }
}

// ─── 문제 1: 테스트 ───
// 스프링 없이 순수 Java 테스트:
OrderService os = new OrderService();
// paymentService = null!
// @Autowired는 스프링이 처리. 스프링 없으면 null 그대로.
// os.order() → NullPointerException 발생

// ─── 문제 2: final 불가 ───
// @Autowired private final PaymentService paymentService;
// → 컴파일 에러! final은 선언 시 또는 생성자에서만 초기화 가능
// → @Autowired는 생성자 이후에 주입하므로 final 불가

@Service
public class NotificationService {

    private EmailService emailService; // final 없음

    @Autowired
    @Required // 필수 주입 표시 (선택)
    public void setEmailService(EmailService emailService) {
        this.emailService = emailService;
        // ↑ Setter 메서드. 스프링이 이 메서드를 호출해서 주입.
        //
        // 스프링 실행 순서:
        // Step 1: new NotificationService() → Heap 객체 생성 (emailService = null)
        // Step 2: 스프링이 setEmailService(emailServiceBean) 호출
        //         → Stack에 setEmailService() 프레임 push
        //         → this.emailService = emailServiceBean 실행
        //         → 프레임 pop
        //
        // ⚠️ 문제: setEmailService()를 호출하지 않으면
        //    emailService = null → 나중에 사용 시 NPE
    }

    public void sendNotification() {
        // emailService가 null이면 여기서 NPE
        emailService.send("알림!");
    }
}

// Setter 주입이 유용한 경우:
// - 선택적 의존성: emailService가 없어도 동작해야 할 때
// public void sendNotification() {
//     if (emailService != null) emailService.send("알림!");
// }
// - 순환참조 해결이 필요한 레거시 코드 (거의 없음)

━━━━━━━━ Before (Lombok 없이 — 직접 생성자 작성) ━━━━━━━━

@Service
public class BoardService {

    private final BoardRepository boardRepository;
    private final UserRepository userRepository;
    private final JwtUtil jwtUtil;

    // 의존성 3개 → 생성자 직접 써야 함
    public BoardService(
            BoardRepository boardRepository,
            UserRepository userRepository,
            JwtUtil jwtUtil) {
        this.boardRepository = boardRepository;
        this.userRepository = userRepository;
        this.jwtUtil = jwtUtil;
    }
}

━━━━━━━━ After (Lombok 사용 — 실무 표준) ━━━━━━━━━━━━━

@Service
@RequiredArgsConstructor
// ↑ Lombok: final 필드를 모두 받는 생성자를 컴파일 시 자동 생성
//   → 위의 생성자 코드를 자동으로 만들어줌
//   → @Autowired 없어도 됨 (생성자가 하나뿐이면 스프링이 자동 인식)
public class BoardService {

    private final BoardRepository boardRepository;
    private final UserRepository userRepository;
    private final JwtUtil jwtUtil;
    // 이게 전부. 생성자 코드 없음.
}

━━━━━━━━ @RequiredArgsConstructor 동작 원리 ━━━━━━━━━━

// 컴파일 시 Lombok이 자동으로 아래 코드 생성 (보이지 않지만 .class에 포함)
public BoardService(
        BoardRepository boardRepository,
        UserRepository userRepository,
        JwtUtil jwtUtil) {
    this.boardRepository = boardRepository;
    this.userRepository = userRepository;
    this.jwtUtil = jwtUtil;
}

// 규칙:
// - final 필드 = 반드시 포함 (Required)
// - final 아닌 필드 = 제외
// - @NonNull 붙은 필드 = 포함 + null 체크 코드 추가
//
// JVM 메모리 관점: 완전히 동일
// 생성자 주입을 직접 쓴 것과 동일하게 동작
// Heap 연결, final 보장, Stack 프레임 생성/pop 모두 동일