이번장의 핵심은...
클래스가 내부적으로 하나 이상의 자원에 의존하고,
그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스를 사용하지 않는 것이 좋다!
클래스가 직접 생성해서도 안되고,
필요한 자원을 생성자에 넘겨주자
-> '의존 객체 주입' 이라 하는 이 기법은 유연성, 재사용성, 테스트 용이성을 기막히게 개선해준다
정적 유틸리티 클래스와 싱글턴을 잘못 사용한 예를 보자
이런 코드는 유연하지 않고 테스트하기 어렵다
// 정적 유틸리티를 잘못 사용
public class SpellChecker {
private static final Lexicon dictionary = ...;
private SpellChecker() {} // 객체 생성 방지
}
// 싱글턴을 잘못 사용
public class SpellChcker {
private final Lexicon dictionary = ...;
private SpellChecker(..) {}
public SpellChecker INSTANCE = new SpellChecker(..);
}
두 방식 모두 dictionary를 단 1개만 사용한다고 가정한다는 점에서 좋지 않다
실전에서는 국어사전, 영어사전, 특수 어휘용 사전 등등 다양한 사전이 존재할 수 있다
사전 1개로 이 모든 쓰임을 대응할 수 없다
그러면, SpellChecker 클래스가 여러 사전을 사용할 수 있도록 수정해보자
단순하게 필드에서 final 한정자를 제거하고 다른 사전으로 교체하는 메서드를 추가할 수 있지만,
멀티스레드 환경에서 사용할 수없다
사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다
의존 객체 주입
SpellChecker가 클라이언트가 원하는 자원 인스턴스를 지원해야 한다
그러면 클라이언트가 인스턴스를 생성할 때, 생성자에 필요한 자원을 넘겨주면 된다
즉, 의존 객체 주입의 한 형태로,
SpellChecker 인스턴스를 생성할 때, 의존객체인 dictionary를 주입해준다
public class SpellChecker {
private final Lexicon dictionary;
public SpellChecker(Lexicon dictionary) {
this.dictionary = Objects.requireNonNull(dictionary);
}
}
이러한 패턴의 쓸만한 변형으로 팩터리 메서드 패턴이 있다
팩터리 메서드 패턴과 관련된 내용은 따로 포스팅해두려고 한다
간단히 설명하면, 생성자에 자원 팩터리를 넘겨주는 방식이다
(팩터리 : 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체)
자바 8에서 소개한 Supplier<T> 인터페이스가 팩터리를 표현한 완벽한 예이다
의존 객체 주입이 유연성, 테스트 용이성을 개선해주긴 하지만,
의존성이 아주 큰 프로젝트에서는 코드를 어지럽게 만듬
하지만,
대거, 주스, 스프링과 같은 의존 객체 주입 프레임워크를 사용하면 이런 어질러짐은 해소된다
'Java > Effective Java 3E' 카테고리의 다른 글
[이펙티브자바 3판] ITEM7. 다 쓴 객체 참조를 해제하라 (메모리 누수) (0) | 2020.09.07 |
---|---|
[이펙티브자바 3판] ITEM6. 불필요한 객체 생성을 피하라 (0) | 2020.09.06 |
[이펙티브자바 3판] ITEM63. 문자열 연결은 느리니 주의하라 (0) | 2020.09.05 |
[이펙티브자바 3판] ITEM4. 인스턴스화를 막으려거든 private 생성자를 사용하라 (0) | 2020.09.05 |
[이펙티브자바 3판] ITEM3. private 생성자나 열거타입으로 싱글턴임을 보증하라 (0) | 2020.09.04 |
댓글