3.2.6 수정자 주입 vs. 생성자 주입

이제 어떤 IoC 방식이 더 나은지 결론을 내렸지만, 수정자 주입(setter injection)과 생성자 주입(constructor injection) 중 어느 방식을 사용해야 하느냐는 선택이 여전히 남아 있습니다. 특히, 생성자 주입은 컴포넌트 사용 전에 해당 컴포넌트의 의존성을 반드시 갖고 있어야 할 때 매우 유용합니다. 스프링을 포함한 많은 컨테이너는 수정자 주입을 사용할 때도 모든 의존성을 확인할 수 있는 메커니즘을 제공하긴 하지만, 생성자 주입을 사용하면 컨테이너가 의존성 점검 메커니즘을 제공하는지와 상관없이 의존성에 대한 요구사항을 지정할 수 있습니다. 또한, 생성자 주입을 사용하면 빈 객체를 불변 객체(immutable object)로 사용할 수 있습니다.

수정자 주입은 다양한 상황에서 유용합니다. 컴포넌트가 의존성을 컨테이너로 노출하지만, 기본 의존성을 제공할 때는 일반적으로 수정자 주입이 의존성 주입에 가장 좋은 방법입니다. 수정자 주입의 또 다른 장점은, 생각보다 유용하지 않을지도 모르지만, 인터페이스에서 모든 의존성을 선언할 수 있다는 것입니다.

defineMeaningOfLife()라는 비즈니스 메서드 하나를 가진 전형적인 비즈니스 인터페이스가 있다고 가정해 보겠습니다. defineMeaningOfLife() 메서드 외에 setEncyclopedia() 같은 의존성 주입 메서드를 인터페이스에 정의하는 것은 해당 인터페이스의 모든 구현체가 encyclopedia 의존성을 사용하거나 최소한 인지하도록 강제하는 것입니다. 하지만 비즈니스 인터페이스에서 setEncyclopedia()를 정의할 필요는 없습니다. 대신 비즈니스 인터페이스를 구현하는 클래스에서 이 메서드를 정의하면 됩니다. 이렇게 프로그래밍하면 스프링을 비롯한 최근의 모든 IoC 컨테이너는 사용자의 비즈니스 인터페이스를 사용해 사용자의 컴포넌트를 동작시키면서 구현 클래스의 의존성도 제공합니다. 다음 예제를 보면 이 문제를 좀 더 명확히 이해할 수 있을 것입니다. 다음 비즈니스 인터페이스 코드를 살펴보겠습니다.