스프링 프레임워크의 의존성 주입 기법 - 생성자 주입, 수정자 주입, 필드 주입 (왜 생성자 주입을 사용해야 하는가?)

스프링 프레임워크는 객체 지향 프로그래밍의 핵심 원칙인 '의존성 역전 원칙'을 구현하는 데 있어서 의존성 주입(Dependency Injection, DI)을 중심으로 활용합니다. 이를 통해 애플리케이션의 결합도를 낮추고, 유연성 및 확장성을 향상시킬 수 있습니다. 여기서는 스프링에서 주로 사용되는 세 가지 의존성 주입 방식인 생성자 주입(Constructor Injection), 수정자 주입(Setter Injection), 필드 주입(Field Injection)에 대해 자세히 알아보고, 각 방법의 특징과 장단점을 설명하겠습니다.

1. 생성자 주입(Constructor Injection)

생성자를 통한 의존성 주입은 객체가 생성될 때 모든 의존성이 충족되어야 함을 의미합니다. 생성자 인자를 통해 모든 필요한 의존성을 제공받기 때문에, 객체가 사용되기 시작할 때 이미 모든 의존성이 존재하게 됩니다. 이는 객체가 언제나 완전하고 일관된 상태로 있도록 보장합니다. 만약 의존성이 충족되지 않는다면, 객체는 아예 생성되지 않기 때문에 런타임에 발생할 수 있는 의존성 관련 오류를 사전에 방지할 수 있습니다.

예시 코드:

public class BookService {
    private final BookRepository repository;

    public BookService(BookRepository repository) {
        this.repository = repository;
    }
}

예시 코드 세부 동작 순서:

1. BookService 객체 생성 요청.
2. BookRepository 인스턴스가 필요함을 스프링이 인지.
3. BookRepository 인스턴스를 생성하거나 기존에 존재하는 빈을 찾음.
4. BookRepository 인스턴스를 BookService 생성자에 주입하며 객체 생성.
5. 전체 동작 순서:
6. 의존성 확인: 스프링 컨테이너는 객체를 생성하기 전에 필요한 의존성을 먼저 확인합니다.
7. 빈 생성 및 주입: 필요한 의존성을 생성자의 인자로 전달하면서 객체(빈)를 생성합니다.

장점:

• 안정성: 의존성이 명시적이므로 생성자를 통해 안정적으로 객체를 초기화할 수 있습니다.
• 불변성: 의존성 주입 후에는 변경이 불가능하여 객체의 상태가 일관됩니다.
• 순환 참조 오류 확인 가능: 서로 의존하는 객체 간에 순환 참조가 발생할 경우, 스프링은 객체를 생성할 수 없어 오류가 발생합니다.(생성자를 통해 모든 의존성이 주입되기 때문에, 순환 참조가 있을 경우 스프링은 애플리케이션의 초기화 단계에서 이를 감지하고 에러를 발생)

2. 수정자 주입(Setter Injection)

수정자 주입은 객체 생성 후, 필요한 의존성을 setter 메서드를 통해 주입하는 방식입니다. 이는 객체의 생성과 의존성 주입을 분리하여 더 유연한 구성이 가능하게 합니다.

예시 코드:

public class UserService {
    private UserRepository userRepository;

    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

예시 코드 상세 동작 순서:

1. UserService 객체 생성.
2. 스프링이 UserRepository 의존성을 확인.
3. UserRepository 인스턴스를 UserService의 setUserRepository 메서드를 통해 주입.

전체 동작 순서:

1. 빈 생성: 스프링 컨테이너는 먼저 객체(빈)를 생성합니다. 이 때는 아직 의존성이 주입되지 않은 상태입니다.
2. 의존성 확인: 스프링 컨테이너는 객체에 필요한 의존성을 확인합니다.
3. 의존성 주입: 스프링 컨테이너는 해당 객체의 수정자 메서드(setter)를 호출하여 의존성을 주입합니다.

장점:

• 유연성: 의존성을 나중에 주입할 수 있어 실행 중에 객체의 의존성을 변경할 수 있습니다.
• 선택적 의존성: 모든 의존성이 필수는 아니므로 필요에 따라 선택적으로 의존성을 주입할 수 있습니다.

단점:

• 불완전한 객체 생성 가능성: 모든 의존성이 설정되기 전에 객체를 사용할 위험이 있습니다.

3. 필드 주입(Field Injection)

필드 주입은 클래스 내부의 필드에 직접 의존성을 주입하는 방식입니다. 주로 @Autowired 어노

테이션을 사용하여 간편하게 의존성을 주입할 수 있습니다.

예시 코드:

public class OrderService {
    @Autowired
    private PaymentService paymentService;
}

예시 코드 동작 순서:

1. OrderService 객체 생성.
2. 스프링이 PaymentService 필드에 @Autowired를 인식.
3. 해당 필드에 PaymentService 인스턴스를 자동으로 주입.

전체 동작 순서:

1. 빈 생성: 객체(빈)가 생성됩니다.
2. 의존성 주입: 생성된 객체의 필드에 어노테이션이 붙어 있는 경우, 스프링 컨테이너는 해당 필드에 직접 의존성을 주입

장점:

• 간결성: 코드가 간단해져서 개발 속도가 향상됩니다.
• 편리성: 설정자 메서드나 생성자를 정의할 필요 없이 자동으로 의존성이 관리됩니다.

단점:

• 테스트 어려움: 단위 테스트 시 의존성을 명시적으로 제공하기 어려워집니다.

즉 왠만해선 생성자 주입을 사용해야 하며

생성자 주입의 장점을 전체적으로 자세히 나열해보겠다

왜 생성자 주입을 사용해야 하는가?

1. 의존성 명확성과 안전성

생성자를 통해 의존성을 주입받는 방식은 모든 필수 의존성이 생성 시점에 제공되어야 함을 의미합니다. 이 접근 방식은 의존성 누락을 방지하고, 런타임 오류의 가능성을 줄입니다.

예시 코드:

public class AccountService {
    private final AccountRepository accountRepository;
    private final NotificationService notificationService;

    public AccountService(AccountRepository accountRepository, NotificationService notificationService) {
        this.accountRepository = accountRepository;
        this.notificationService = notificationService;
    }
}

위 코드에서 AccountService는 AccountRepository와 NotificationService의 의존성을 필요로 합니다. 이 두 컴포넌트는 생성자를 통해 주입되므로, AccountService 객체는 항상 완전한 상태로 생성됩니다.

2. 불변성 보장

생성자 주입을 통한 의존성 관리는 객체의 불변성을 보장합니다. 한 번 주입된 의존성은 객체의 생명주기 동안 변경되지 않습니다.

예시 코드:

public class Configuration {
    private final String databaseUrl;

    public Configuration(String databaseUrl) {
        this.databaseUrl = databaseUrl;
    }

    public String getDatabaseUrl() {
        return this.databaseUrl;
    }
}

Configuration 객체는 생성 시 databaseUrl을 주입받으며, 이 값은 객체가 존재하는 동안 변경될 수 없습니다. 이는 객체의 일관된 상태를 유지하는 데 중요합니다.

3. 순환 참조 방지

생성자 주입은 순환 참조를 컴파일 시점에서 감지할 수 있게 해줍니다. 서로 의존하는 객체가 있을 경우, 스프링은 초기화 중에 에러를 발생시켜 개발자에게 알립니다.

순환 참조 발생 예:

public class ClassA {
    private final ClassB classB;

    public ClassA(ClassB classB) {
        this.classB = classB;
    }
}

public class ClassB {
    private final ClassA classA;

    public ClassB(ClassA classA) {
        this.classA = classA;
    }
}

위 코드는 ClassA와 ClassB가 서로를 필요로 하므로 순환 참조가 발생합니다. 스프링은 이를 감지하고 객체 생성을 중단합니다.

4. 테스트 용이성

생성자 주입은 테스트 중에 의존성을 쉽게 제어할 수 있게 해줍니다. 테스트 시에 필요한 의존성을 목 객체로 제공할 수 있습니다.

예시 코드:

public class UserServiceTest {
    @Test
    public void testUserService() {
        UserRepository mockRepository = mock(UserRepository.class);
        NotificationService mockService = mock(NotificationService.class);
        UserService userService = new UserService(mockRepository, mockService);

        // 테스트 실행
        userService.performUpdate();

        // 상태 검증
        verify(mockRepository).update(any(User.class));
        verify(mockService).sendNotification(any(String.class));
    }
}

위 코드에서 UserService의 테스트는 목 객체를 생성자를 통해 주입하여, 실제 의존성을 모방합니다. 이 방식은 테스트가 의존성의 구체적인 구현에 묶이지 않도록 해줍니다.