많은 클래스는 하나 이상의 자원에 의존한다.

 

예를 들어, 맞춤법 검사기를 생각해보자.
맞춤법 검사기는 사전에 의존한다. 따라서, 사전 하나로 모든 맞춤법 검사를 하는 것은 불가능하다.

맞춤법 검사는 사용하는 사전에 따라서 동작이 달라진다.

 

이러한 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.
이러한 경우, 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식인 의존 객체 주입을 사용한다.

 

샘플 코드

public class SpellChecker {
    private final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary) {
        this.dictionary = dictionary;
    }

    //...
}

이 패턴을 사용할 경우,

  • 자원이 몇 개든 의존 관계가 어떻든 상관없이 잘 동작한다.
  • 불변(아이템 17)을 보장하여 (같은 자원을 사용하려는) 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있다.

 

이 패턴은 정적 팩터리(아이템1)과 빌더(아이템2)에 똑같이 응용할 수 있다.

또, 팩토리 메서드 패턴(Factory Method pattern)으로 변형이 가능하다.


팩터리 메서드 패턴이란 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체를 뜻한다.

Supplier<T> 인터페이스가 이의 완벽한 예이다.
Supplier<T>를 입력으로 받는 메서드는 일반적으로 한정적 와인드카드 타입(bounded wildcard type, 아이템 31)을 사용해 팩터리의 매개변수를 제한한다.

요약!!

의존 객체 주입을 사용하면 클래스의 유연성, 재사용성, 테스트 용이성을 기가막히게 개선해준다.
하지만, 의존 객체 주입이 유연성과 테스트 용이성을 개선해주기도 하지만, 의존성이 수천 개나 되는 큰 프로젝트에서는 코드를 어지럽게 만들기도 한다.
대거(Dagger), 주스(Guice), 스프링(Spring)과 같은 객체 주입 프레임워크를 사용하면 이를 좀 해결할 수 있다!

반응형
복사했습니다!