[F-Lab 페이백 모각코 57일차] 스프링에서 생성자 주입을 권장하는 이유

스프링에서 생성자 주입을 권장하는 이유

스프링 프레임워크에서 생성자 주입을 권장하는 이유에는 여러 가지가 있습니다. 주요한 이유들은 다음과 같습니다:

1. 불변성(Immutability):
   • 필드 주입이나 세터 주입을 사용하면, 객체가 생성된 후에도 해당 필드의 값이 변경될 가능성이 있습니다. 반면, 생성자 주입을 사용하면 모든 필요한 의존성이 객체 생성 시점에 한 번에 주입되므로, 이후에 변경될 위험이 없습니다.
   • 이러한 불변성은 객체의 안정성을 보장하며, 동시성 이슈를 줄이는 데에도 도움이 됩니다.
2. 의존성 명시적 표현:
   • 생성자의 매개변수로 주입되는 의존성들은 해당 클래스가 정상적으로 동작하기 위해 필요한 의존성들임을 명확히 나타냅니다.
   • 세터나 필드 주입의 경우, 어떤 의존성이 필수적이고 어떤 것이 선택적인지 구분하기 어렵습니다.
3. 순환 의존성 문제 감지:
   • 생성자 주입을 사용할 경우, 빈이 초기화되는 시점에 순환 의존성이 있으면 스프링이 바로 예외를 발생시킵니다. 이로써 순환 의존성 문제를 빠르게 인지하고 수정할 수 있습니다.
4. 테스트 용이성:
   • 생성자 주입은 테스트 시에도 간편합니다. 테스트에서는 스프링 컨텍스트 없이 객체를 생성하고, 생성자를 통해 의존성을 주입할 수 있습니다. 이로써 단위 테스트가 간결하고 명확해집니다.
5. 코드의 명료성:
   • 생성자를 통해 어떤 의존성이 필요한지 한눈에 파악하기 쉽습니다. 이는 코드의 가독성과 유지 보수성을 향상시킵니다.
6. 프레임워크와의 결합도 감소:
   • 생성자 주입은 순수한 자바 코드로 의존성을 주입하는 방법이므로, 특정 프레임워크나 라이브러리에 의존하지 않습니다. 이는 결합도를 낮추며, 다른 환경이나 테스트 케이스에서의 사용이 용이하게 됩니다.

이러한 이유들로 인해, 스프링은 생성자 주입 방식을 권장하며, 현대의 많은 스프링 기반 프로젝트에서는 생성자 주입을 기본으로 사용하고 있습니다.

스프링 프레임 워크에서 생성자 주입의 역활과 기능과 필요성

스프링 프레임워크에서의 생성자 주입은 의존성 주입(Dependency Injection, DI)의 한 형태입니다. 다음은 생성자 주입의 역할, 기능, 그리고 필요성에 대해 자세히 설명하겠습니다:

1. 역할:

• 의존성 주입: 클래스 내부에서 필요로 하는 의존 객체를 외부에서 주입받는 역할을 합니다. 이를 통해 객체 간의 결합도를 낮추고, 모듈화 및 재사용성을 향상시킬 수 있습니다.

2. 기능:

• 객체의 불변성 유지: 한번 객체가 생성되면 그 상태를 변경할 수 없도록 해, 객체의 안정성을 보장합니다.
• 명시적 의존성: 생성자의 매개변수를 통해 해당 클래스가 어떤 의존성을 가지는지 명확하게 표현합니다.
• 순환 의존성 확인: 생성자 주입 방식은 순환 의존성이 있을 경우 초기화 시점에 에러를 발생시켜, 개발자에게 바로 알려줍니다.
• 단일 책임 원칙(SRP) 강조: 생성자에 주입되는 의존성이 많다면 해당 클래스가 너무 많은 역할을 하는 것이 아닌지 고민할 수 있게 해줍니다.

3. 필요성:

• 결합도 감소: 의존성 주입을 사용하면 구체적인 클래스에 의존하지 않고 인터페이스에만 의존하게 되므로, 시스템의 유연성과 확장성이 향상됩니다.
• 테스트 용이성: 외부에서 의존 객체를 주입받을 수 있기 때문에, 테스트 시에 모의 객체(Mock Object)나 스텁(Stub)을 쉽게 주입할 수 있습니다.
• 코드의 명료성: 어떤 의존성을 가지는지 생성자를 통해 명확하게 파악할 수 있어, 코드의 가독성이 향상됩니다.
• 객체 생명주기 관리: 스프링 컨테이너는 빈(Bean)의 생명주기를 관리하며, 생성자 주입을 통해 필요한 의존성을 적절한 생명주기에 맞게 주입해줍니다.

결과적으로, 생성자 주입은 스프링 프레임워크에서 객체 지향 원칙을 준수하며, 높은 품질의 코드를 작성하는 데 중요한 역할을 합니다. 이로 인해 개발자는 보다 견고하고, 유지보수하기 쉬운 애플리케이션을 구축할 수 있습니다.

스프링 프레임 워크에서 생성자 주입 종류

스프링 프레임워크에서 제공하는 주입 방법은 크게 세 가지로 분류됩니다: 생성자 주입, 세터 주입, 필드 주입입니다. 여기서는 생성자 주입의 종류에 중점을 둬서 설명하겠습니다.

1. 생성자 주입(Constructor Injection)

생성자 주입은 해당 클래스의 생성자를 통해 의존성을 주입받는 방법입니다.

장점:

• 불변성(Immutability)을 보장할 수 있습니다. 한번 주입된 의존성은 변경되지 않습니다.
• 필요한 의존성 없이 인스턴스 생성이 불가능하므로 객체가 올바른 상태로 생성됩니다.
• 순환 참조가 있을 때 스프링이 에러를 발생시켜 쉽게 발견할 수 있습니다.

사용 방법:

@Component
public class SampleService {

    private final SampleRepository sampleRepository;

    @Autowired
    public SampleService(SampleRepository sampleRepository) {
        this.sampleRepository = sampleRepository;
    }
}

스프링 4.3부터는 생성자가 하나만 존재하는 경우 @Autowired 어노테이션을 생략할 수 있습니다.

2. 세터 주입(Setter Injection)

세터 주입은 해당 클래스의 세터 메서드를 통해 의존성을 주입받는 방법입니다.

장점:

• 선택적인 의존성 주입이 가능합니다.

단점:

• 객체 생성 후에도 의존성을 변경할 수 있기 때문에 불변성을 보장할 수 없습니다.

사용 방법:

@Component
public class SampleService {

    private SampleRepository sampleRepository;

    @Autowired
    public void setSampleRepository(SampleRepository sampleRepository) {
        this.sampleRepository = sampleRepository;
    }
}

3. 필드 주입(Field Injection)

필드 주입은 클래스의 필드 변수에 바로 주입하는 방법입니다.

단점:

• 불변성을 보장할 수 없습니다.
• 테스트하기 어려울 수 있습니다.

사용 방법:

@Component
public class SampleService {

    @Autowired
    private SampleRepository sampleRepository;
}

여기서 중요한 것은, 스프링에서는 생성자 주입을 권장하고 있습니다. 생성자 주입을 사용하면 불변성과 필수 의존성을 보장할 수 있기 때문입니다.

3가지 주입 방법 중 많이 쓰이는 주입 방법

스프링 커뮤니티와 개발자들 사이에서는 **생성자 주입(Constructor Injection)**이 가장 권장되고 널리 사용되는 주입 방법입니다. 그 이유는 다음과 같습니다:

1. 불변성(Immutability): 생성자 주입을 사용하면 해당 클래스의 의존성이 한 번 설정된 후 변경되지 않습니다. 이로 인해 객체의 상태가 안정적이며, 사이드 이펙트를 줄일 수 있습니다.
2. 순환 참조 감지: 생성자 주입을 사용하면 스프링이 순환 참조를 발견할 때 예외를 발생시켜주기 때문에, 애플리케이션 구조상의 문제점을 빠르게 인지할 수 있습니다.
3. 테스트 용이성: 생성자를 통해 의존성을 주입받게 되면, 테스트 시에도 쉽게 목(mock) 객체나 다른 구현체를 주입하여 테스트할 수 있습니다.

세터 주입이나 필드 주입은 필요에 따라 유연하게 의존성을 변경하고 싶을 때나, 선택적인 의존성 주입이 필요한 경우에 사용할 수 있습니다. 하지만, 위에서 언급한 이유로 인해 생성자 주입이 가장 권장되며, 대부분의 상황에서 생성자 주입을 사용하는 것이 좋습니다.

사용 예시

@Service
public class MyService {
    
    private final AnotherService anotherService;
    
    public MyService(AnotherService anotherService) {
        this.anotherService = anotherService;
    }
}