비즈니스 인터페이스 내에서 구성 옵션을 정의할지 말지 고민된다면 구성 인자가 비즈니스 인터페이스의 모든 구현체에서 사용될지, 단 하나의 구현체에서만 사용될지 고려하기 바랍니다. 예를 들어 모든 NewsletterSender 구현체는 이메일을 보낼 때 SMTP 서버를 알아야 합니다. 하지만 모든 이메일 API가 보안 기능을 지원하지 않으며 대다수 구현체가 보안을 전혀 고려하지 않았다고 가정하는 것이 더 정확할 것이므로 보안 이메일을 보낼지 여부를 나타내는 구성 옵션을 인터페이스에서 제외하는 것이 더 좋을 것입니다.
Note 2장에서 비즈니스 목적에 따라 의존성을 정의하기로 했었던 것을 기억할 것입니다. 이는 설명을 위해 사용된 것으로 모범 사례로 보여주기 위한 예제는 아니었습니다.
수정자 주입을 사용하면 부모 컴포넌트의 인스턴스를 새로 생성하지 않고도 즉시 의존성을 다른 구현체로 교체할 수 있습니다. 이는 스프링의 JMX 지원 기능 덕분에 가능합니다. 아마도 수정자 주입의 가장 큰 장점은 주입 메커니즘 중 가장 자유롭게 사용할 수 있다는 것입니다.
일반적으로 사용 사례에 따라 주입 방식을 선택해야 합니다. 수정자 주입을 사용하면 새로운 객체를 생성하지 않아도 의존성을 교체할 수 있고, 명시적으로 객체를 주입하지 않더라도 적절한 기본값을 선택하게 할 수 있습니다. 생성자 주입은 컴포넌트에 의존성 주입을 보장하거나 불변 객체를 설계하는 경우에 좋은 선택입니다. 생성자 주입이 컴포넌트에 필요한 모든 의존성 제공을 보장하지만, 대부분의 컨테이너도 의존성 제공을 보장하는 메커니즘을 제공하며 이때는 사용자 코드를 프레임워크에 결합해야 하는 부담이 따를 수 있다는 점을 명심하기 바랍니다.