객체를 만들어야 할 때와, 만들지 말아야 할 때를 구분하는 법.
올바른 객체 생성방법과, 불필요한 생성을 피하는 방법.
제때 파괴됨을 보장하고, 파괴 전에 수행해야 할 정리 작업을 관리 하는 요령.
위의 방법들을 자세히 알아보자.
아이템 1) 생성자 대신 정적 팩터리 메서드를 고려하라
보통 public 생성자를 통해 클래스의 인스턴스를 얻게 된다.
하지만 이외에도 정적 팩터리 메서드(static factory method)를 통해 같은 역할을 수행할 수 있다.
(디자인 패턴인 factory method 와는 다름)
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}
이 코드는 boolean의 기본 타입의 박싱 클래스인 Boolean으로 값을 변환해주는 코드이다.
장점
- 이름을 가질 수 있다.
생성자의 이름과 매개변수만을 가지고는 어떤 역할을 하는지 알기 어려우나, 메서드에 이름을 잘 지으면 알 수 있다.
// 값이 소수인 BigInteger를 반환한다
//1
public BigInteger(int, int, Random)
//2
BigInteger.probablePrime
생성자는 매개변수의 변화를 통해 다양한 역할을 하지만, 어떤 역할을 하는지 제대로 알기 어렵기 때문에 개발자가 API를 잘못 호출하는 실수를 야기할 수도 있다. 또한, 코드를 읽는 사람도 API 문서를 읽으며 어떤 역할을 하는지 찾아봐야 한다.
정적 팩터리 메서드는 이름만으로도 쉽게 구별이 가능하기 때문에 가독성이 좋다.
- 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.
불변 클래스(immutable class)는 인스턴스를 미리 만들거나, 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다.
Boolean.valueOf(boolean)
=> 객체를 아예 생성하지 않기 떄문에, 자주 호출되는 경우 성능을 높일 수 있다. (플라이웨이트 패턴과 유사)
반복되는 요청에 같은 객체를 반환하는 식으로 인스턴스를 통제할 수 있다. 이를 인스턴스 통제 클래스라고 한다.
(싱글턴, 인스턴스화 불가(noninstantiable)로 만들기도 가능)
a == b 일때만 a.equals(b)가 성립하는 것과 같이 동치인 인스턴스가 단 하나 뿐임을 보장할 수 있다.
즉, 불변 값 클래스에서 동치 인스턴스가 단 하나 뿐임을 보장할 수 있다.
- 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
즉, 반환할 객체의 클래스를 자유롭게 선택할 수 있어 유연하게 개발이 가능하다.
이는 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크를 만드는 핵심이다.
인터페이스가 정적 메서드를 가질 수 있기 때문에, 동반클래스에 두었던 public 정적 멤버들을 그냥 인터페이스에 두면 된다.
*동반 클래스: 불변 객체(Immutable Object)와 함께 사용되는 클래스로, 불변 객체를 보완하고 더 유연하게 사용할 수 있도록 돕는 역할
ex) String(불변객체), StringBuilder(동반 클래스)
하지만 private 클래스에 두어야 할 때, 자바 8은 public만 허용하기 때문에 불가하며, 자바 9부터는 private 정적 메서드까지 허락하기 때문에 가능하다.
- 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다.
EnumSet 클래스는 public 생성자 없이, 정적 팩터리만 제공하는데 OpenJDK에서는 원소의 수에 따라 두 가지 하위 클래스 중 하나의 인스턴스를 반환한다.
클라이언트는 이 하위 클래스의 존재를 모르기 때문에 중간에 클래스를 삭제해서 릴리즈해도, 추가해도 상관없다. EnumSet의 하위 타입이기만 하면 된다.
- 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.
서비스 제공자 프레임워크는 세 개의 구성요소로 이루어져 있다.
- 서비스 인터페이스: 구현체의 동작을 정의하는 서비스 인터페이스
- 제공자 등록 API: 제공자가 구현체를 등록할 때 사용하는 제공자 등록 API
- 서비스 접근 API: 클라이언트가 서비스의 인스턴스를 얻을 때 사용
클라이언트는 서비스 접근 API를 사용할 때 원하는 구현체의 조건을 명시할 수 있다.
조건을 명시하지 않으면 기본 구현체를 반환하거나 지원하는 구현체들을 하나씩 돌아가며 반환한다.
단점
- 상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
상속보다 컴포지션을 사용하도록 유도, 불변 타입으로 만들려면 이 제약을 지켜야 한다.
- 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.
생성자처럼 API 설명에 명확히 드러나지 않으니 사용자는 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 한다.
이를 위해 API 문서를 작성하거나, 메서드 이름을 알기 쉽게 명명해야 한다.
- from: 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드
- of: 여러 매개변수를 받아 적합한 타입의 인스턴스르르 반환하는 집계 메서드
- valueOf: from과 of의 더 자세한 버전.
- instance(getInstance): 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지는 않는다.
- create(newInstance): instance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다.
- getType: getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다.
- newType: newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. ex) BufferedReader br = newBufferrdReader(path);
- type: getType과 newType의 간결한 버전 ex) List<Point> l = Collections.list(ls);
아이템 2) 생성자에 매개변수가 많다면 빌더를 고려하라
정적 팩터리와 생성자에는 똑같은 제약이 있다. 바로 선택적 매개변수가 많을 때 대응이 어렵다는 점이다.
예를들어 매개변수가 6개인 메서드가 있다고 할때 이에 값을 넣어줘야 한다고 하면 몇 개의 생성자가 필요할까?
이럴때 사용하는 방법이 바로 점층적 생성자 패턴(telescoping constructor pattern)이다.
필수 매개변수만 받는 생성자, 필수와 선택 매개변수 1개를 받는 생성자, 2개를 받는 생성자 ... 의 형태로 선택 매개변수를 전부 다 받는 생성자까지 늘려가는 방식이다.
하지만 이런 방식을 사용하면 매개변수의 개수가 많아질수록 코드를 작성하기도 어렵고, 가독성도 떨어진다.
매개변수 순서를 실수로 작성하면 컴파일 에러가 아니라 런타임 에러가 발생하기 때문에 오류잡기도 어려워 진다.
이와 다른 방법으로 자바빈즈 패턴(JavaBeans pattern)이 있다.
매개변수가 없는 생성자로 객체를 만든 후, setter 메서드를 호출해 원하는 매개변수의 값을 설정하는 방식이다.
인스턴스를 만들기 쉽고, 가독성이 높다는 장점이 있지만,
자바빈즈 패턴에서는 객체 하나를 만들려면 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성(consistency)이 무너진 상태에 놓인다.
점층적 생성자 패턴에서는 매개변수들이 유효한지를 생성자에서만 확인하면 일관성을 유지할 수 있는데, 자바빈즈 패턴에서는 그게 불가능해 일관성 문제로 에러를 초래하게 된다.
자바빈즈 패턴에서는 클래스를 setter 설정하기 때문에 불변으로 만들 수 없으며, 스레드 안정성을 위해 추가 작업이 필요하다.
=> 생성이 끝난 객체를 수동으로 'freeze'가능 (하지만 실전에서 거의 쓰이지 않음)
빌더 패턴(Builder pattern)은 안정성과 가독성을 가져 유용하게 사용할 수 있다.
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
public static class Builder {
// 필수 매개변수
private final int servingSize;
private final int servings;
// 선택 매개변수 - 기본값으로 초기화한다.
private int calories = 0;
private int fat = 0;
private int sodium = 0;
private int carbohydrate = 0;
public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}
public Builder calories(int val)
{ calories = val; return this; }
public Builder fat(int val)
{ fat = val; return this; }
public Builder sodium(int val)
{ sodium = val; return this; }
public Builder carbohydrate(int val)
{ carbohydrate = val; return this; }
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
private NutritionFacts(Builder builder) {
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate = builder.carbohydrate;
}
public static void main(String[] args) {
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(100).sodium(35).carbohydrate(27).build();
}
}
- 필수 매개변수만으로 생성자를 호출해 빌더 객체를 얻음
- 빌더 객체가 제공하는 세터 메서드들로 원하는 선택 매개변수 설정
- 매개변수가 없는 build 메서드를 호출해 객체를 얻음
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(100).sodium(35).carbohydrate(27).build();
NutritionFacts 클래스는 불변이고, 모든 매개변수의 기본값들을 한곳에 모아뒀다.
builder.XXX를 통해 setter로 값이 설정되고 빌더 자신을 반환하기 때문에 연쇄적으로 호출을 할 수 있다.
이를 플루언트 API 혹은 메서드 연쇄라 한다.
빌더 패턴은 명명된 선택적 매개변수(named optional parameters)를 흉내낸 것이다.
공격에 대비해 불변식을 보장하려면 빌더로부터 매개변수를 복사한 후 해당 객체 필드들도 검사해야 한다.
검사 후 잘못된 점을 알게되면 IllegalArgumentException을 던지면 된다.
빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기 좋다.
Pizza.java
import java.util.*;
public abstract class Pizza {
public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
final Set<Topping> toppings;
abstract static class Builder<T extends Builder<T>> {
EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
public T addTopping(Topping topping) {
toppings.add(Objects.requireNonNull(topping));
return self();
}
abstract Pizza build();
// 하위 클래스는 이 메서드를 재정의(overriding)하여
// "this"를 반환하도록 해야 한다.
protected abstract T self();
}
Pizza(Builder<?> builder) {
toppings = builder.toppings.clone(); // 아이템 50 참조
}
}
NyPizza.java
import java.util.Objects;
public class NyPizza extends Pizza {
public enum Size { SMALL, MEDIUM, LARGE }
private final Size size;
public static class Builder extends Pizza.Builder<Builder> {
private final Size size;
public Builder(Size size) {
this.size = Objects.requireNonNull(size);
}
@Override public NyPizza build() {
return new NyPizza(this);
}
@Override protected Builder self() { return this; }
}
private NyPizza(Builder builder) {
super(builder);
size = builder.size;
}
@Override public String toString() {
return toppings + "로 토핑한 뉴욕 피자";
}
}
Calzone.java
public class Calzone extends Pizza {
private final boolean sauceInside;
public static class Builder extends Pizza.Builder<Builder> {
private boolean sauceInside = false; // 기본값
public Builder sauceInside() {
sauceInside = true;
return this;
}
@Override public Calzone build() {
return new Calzone(this);
}
@Override protected Builder self() { return this; }
}
private Calzone(Builder builder) {
super(builder);
sauceInside = builder.sauceInside;
}
@Override public String toString() {
return String.format("%s로 토핑한 칼초네 피자 (소스는 %s에)",
toppings, sauceInside ? "안" : "바깥");
}
}
Pizza 클래스를 상속받은 NyPizza, Calzone 클래스가 있다.
각 하위 클래스의 빌더가 정의한 build 메서드는 해당하는 구체 하위 클래스를 반환하도록 선언한다.
즉, NyPizza.Builder는 NyPizza를, Calzone.Builder는 Calzone를 반환한다는 것이다.
이를 공변 반환 타이핑(convariant return typing)이라 한다. (형변환을 신경쓰지 않아도 됨)
NyPizza pizza = new NyPizza.Builder(SMALL)
.addTopping(SAUSAGE).addTopping(ONION).build();
Calzone calzone = new Calzone.Builder()
.addTopping(HAM).sauceInside().build();
빌더를 이용하면 가변인수 매개변수를 여러 개 사용할 수 있다.
메서드로 나눠서 선언하거나, 메서드를 여러 번 호출하도록 하고 각 호출 때 넘겨진 매개변수들을 하나의 필드로 모을 수도 있다.
하지만 빌더 패턴을 사용하려면 우선 빌더부터 만들어야 하기 때문에 빌더 생성 비용이 크지는 않지만, 성능에 민감한 상황에는 부적합할 수 있다. (하지만 대부분은 시간이 지나면 기능이 추가되기 때문에 빌더로 시작하 것이 낫다.)
summary
생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 게 더 낫다.
빌더는 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈보다 훨씬 안전하다.
아이템 3) private 생성자나 열거 타입으로 싱글턴임을 보증하라
싱글턴: 인스턴스를 오직 하나만 생성할 수 있는 클래스
ex) 무상태 객체, 설계상 유일해야 하는 컴포넌트
But, 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다.
타입을 인터페이스로 정의하고 구현한 싱글턴이 아니라면 싱글턴 인스턴스를 가짜로 대체할 수 없기 때문이다.
싱글턴 구현 방법
1) public static final 필드 방식
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { }
public void leaveTheBuilding() {
System.out.println("Whoa baby, I'm outta here!");
}
// 이 메서드는 보통 클래스 바깥(다른 클래스)에 작성해야 한다!
public static void main(String[] args) {
Elvis elvis = Elvis.INSTANCE;
elvis.leaveTheBuilding();
}
}
Elvis.INSTANCE를 초기화할때 딱 한 번 private 생성자가 호출된다. (전체 시스템 중 하나임을 보장, final은 불변이기 때문)
2) 정적 팩터리 방식
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() {
System.out.println("Whoa baby, I'm outta here!");
}
// 이 메서드는 보통 클래스 바깥(다른 클래스)에 작성해야 한다!
public static void main(String[] args) {
Elvis elvis = Elvis.getInstance();
elvis.leaveTheBuilding();
}
}
Elvis.getInstance는 항상 같은 객체의 참조를 반환하므로 역시 불변성을 보장한다.
이 방법만의 장점
- API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있게 된다.
- 정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있다.
- 정적팩터리의 메서드 참조를 공급자로 사용할 수 있다. ex)Elvis::getInstance -> Supplier
플렉션 API인 AccessibleObject.setAccessible을 사용해 private 생성자 호출 가능한 예외가 있다.
이런 공격을 방어하려면 생성자를 수정하여 두 번째 객체가 생성되려 할 때 예외를 던지면 된다.
싱글턴 클래스를 직렬화하려면 Serializable만으로는 부족하다.
모든 인스턴스 필드를 일시적(transient)이라고 선언하고 readResolve 메서드를 제공해야 한다.
이렇게 하지 않으면 직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 만들어진다.
private Object readResolve() {
return INSTANCE;
}
이처럼 싱글턴임을 보장해주는 메서드를 만든다. 이를 통해 진짜를 반환하고 가짜는 가비지 컬렉터에 맡긴다.
3) 열거 타입 방식의 싱글턴 (Best)
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() {
System.out.println("기다려 자기야, 지금 나갈께!");
}
// 이 메서드는 보통 클래스 바깥(다른 클래스)에 작성해야 한다!
public static void main(String[] args) {
Elvis elvis = Elvis.INSTANCE;
elvis.leaveTheBuilding();
}
}
이방법은 간결하고, 직렬화가 가능하며, 리플렉션 공격도 막아준다.
원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법이라고 할 수 있다.
단, 만들려던 싱글턴이 Enum외의 클래스를 상속해야 한다면 이 방법은 사용할 수 없다.
아이템 4) 인스턴스화를 막으려거든 private 생성자를 사용하라
정적 메서드, 필드만을 담은 클래스를 만들고 싶을 때가 있다.
java.lang.Math, java.util.Arrays 처럼 기본 타입 값이나 배열 관련 메서드들을 모아 놓을 수 있다.
java.utils.Collcetions 처럼 특정 인터페이스를 구현하는 객첼르 생성해주는 정적 메서드(팩터리)를 모아놓을 수도 있다.
또, final클래스와 관련한 메서드를 모아놓을 때도 사용한다. final 클래스를 상속해서 하위 클래스에 메서드를 넣는건 불가능하기 때문이다.
생성자를 명시하지 않으면 컴파일러는 자동으로 기본 생성자를 만들어준다. (인스턴스화된 클래스)
이 매개변수를 받지 않는 public 생성자는 사용자의 입장에서는 자동생성된 것인지 직접 만든 것인지 알 수 없다.
추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다.
하위 클래스를 만들어 인스턴스화를 하면 되기 때문이다. 이를 보면 상속을 해야 하는 것으로 오인할 수도 있다.
따라서 private 생성자를 만들어두면, 컴파일러가 자동으로 public 생성자를 만들지 않기 때문에 클래스의 인스턴스화를 막을 수 있다.
public class UtilityClass {
// 기본 생성자가 만들어지는 것을 막는다(인스턴스화 방지용).
private UtilityClass() {
throw new AssertionError();
}
// 나머지 코드는 생략
}
private라 클래스 바깥에서는 접근할 수 없지만, 만약 호출하는 경우를 대비해 AssertionError를 던져준다.
모든 생성자는 상위 클래스의 생성자를 호출하게 되는데 private로 선언해 하위 클래스가 상위 클래스의 생성자에 접근하는 걸 막을 수 있다.
아이템 5) 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
많은 클래스가 하나 이상의 자원에 의존한다. 맞춤법 검사기와 사전으로 예를 들어보자.
맞춤법 검사기는 사전에 의존해야 하는데 만약 정적 유틸리티 방식이나 싱글턴 방식으로 구현하게 된다면 어떻게 될까?
맞춤법 검사기가 참조하는 사전은 실전에서는 한 개가 아닐 것이다. 언어별로 여러 개의 사전을 참조해야 하는데 이를 불변으로 한 개만 사용할 수 있게 한다면 유연하지도 않고 테스트하기도 어려울 것이다.
즉, 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.
이런 경우에는 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 의존 객체 주입 방식을 사용해야 한다.
public class SpellChecker {
private final Lexicon dictionary;
public SpellChecker(Lexicon dictionary) {
this.dictionary = dictionary;
}
public boolean isValid(String word) {}
public List<String> suggestions(String typo){}
}
이처럼 자원의 개수와, 의존관계와는 상관 없이 작동하게 할 수 있다.
이 방법은 불변을 보장하며, 여러 클라이언트가 의존 객체들을 공유할 수 있다.
의존 객체 주입은 생성자, 정적 팩터리, 빌더 모두에 응용할 수 있다.
이 방식에 대한 변형으로 생성자에 자원 팩터리를 넘겨주는 방식이 있다. (팩터리 메서드 패턴 구현)
(*팩터리: 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체)
예시로 Supplier<T> 인터페이스가 있다. 입력받는 메서드는 한정적 와일드타입(<T>)를 사용해 팩터리의 타입 매개변수를 제한해야 한다.
이 방식을 사용해 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 팩터리를 넘길 수 있다.
의존 객체 주입이 유연성과 테스트의 용이성을 개선해주기는 하지만, 큰 프로젝트에서는 코드를 어지럽게 만들기도 하다.(의존성이 복잡하므로)
보통 이를 프레임워크들이 도와준다. ex) Dagger, Guide, Spring
https://coding-log.tistory.com/268
[Spring] 스프링 DI란? (Dependency Injection, 의존성 주입) (feat. 객체 조립기)
Spring에는 흔히 말하는 특징 삼대장이 있습니다. DI, AOP, IoC가 바로 그것입니다. 이번 포스팅에서는 DI, 즉 의존 주입에 대해서 다룹니다. 의존이라는 게 도대체 무슨 소리일까요? 여기에서 말하는
coding-log.tistory.com
궁금한 사람은 이 블로그에서도 다룬 적 있으므로 링크를 참조.
Summary
클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 가용하지 않는 것이 좋다.
이 자원들을 클래스가 직접 만들어서도 안되고, 필요한 자원을 생성자에 넘겨주자. (의존성 주입)
의존 객체 주입이라 하는 이 기법은 클래스의 유연성, 재사용성, 테스트 용이성을 개선해준다.