[이펙티브 자바] item 5 - 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

public class SpellChecker {
    private static final Lexicon dictionary = ~~~;
    public static boolean isValid(String word){
        ~~
    }
}

위 정적 유틸리티 클래스(item 4)는 유연하지 않고 테스트하기 어렵다.

사전이 여러개일 가능성이 충분히 충분(?)한데, 위 코드는 다른 사전으로

스펠링을 체크하기 위해선 코드를 수정해야만 한다.

여러 자원 인스턴스를 지원하고, 클라이언트가 원하는 자원(dictionary)을 사용하게 

할 수 있는 유연한 스펠링 체크 클래스로 수정해보자.

■방법 1 :: dictionary set 메소드

dictionary의 final 키워드를 제거하고 set 메소드를 추가하는 방법이다.

이 방식은 Thread-safe하지 않다.

사용하는 자원에 따라 동작이 달라지는 클래스에는 

정적 유틸리티 클래스나 싱글턴 방식이 부적합하다

■방법 2 :: dictionary를 set할수 있는 생성자 (의존 객체 주입 패턴)

private static final Lexicon dictionary = ~~~;

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

Thread-safe한 방법이다.

SpellChecker를 생성할 때 생성자에 원하는 dictionary를 주입한다.

의존 객체 주입은 생성자, 정적 팩터리 메소드, 빌더 모두에 똑같이 응용할 수 있다.

■의존 객체 주입 패턴 변형 :: 팩터리 메서드 패턴

의존 객체 주입 패턴의 변형으로 생성자에 자원 팩터리를 넘겨주는 방식이 있다.

(팩터리 : 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체)

Java 8의 Supplier<T> 인터페이스가 팩터리를 표현한 완벽한 예다.

Supplier<T>를 입력으로 받는 메서드는 일반적으로 한정적 와일드카드 타입(item 31)을 

사용해 팩터리의 타입 매개변수 T를 제한해야 한다. 

왜냐하면 팩토리는 특정 조건의 객체를 만드는 것이 목표이기 때문이다.

이 방식을 사용해 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든

생성할 수 있는 팩터리를 넘길 수 있다. 

예컨대 다음 코드는 클라이언트가 제공한 팩터리가 생성한 타일(Tile)들로 구성된

모자이크(Mosaic)를 만드는 메서드다.

Moszic create(Supplier<T extends Tile> tileFactory) {}

■의존 객체 주입 프레임워크

의존 객체 주입이 유연성과 테스트 용이성을 개선해주긴 하지만, 의존성이 수천개나 되는

큰 프로젝트에서는 코드를 어지럽게 만들기도 한다.

- Dagger

- Guice

- Spring

위와 같은 의존 객체 주입 프레임워크를 사용하면 이런 어질러짐을 

해소할 수 있다.