[이펙티브 자바] 2장 : 객체 생성과 파괴

2장 객체 생성과 파괴

객체를 ‘만들어야 하는 시기'를 구분하는 방법

불필요한 생성을 피하는 방법

제때 파괴됨을 보장하고 파괴전에 수행해야할 작업 처리 방법

아이템 1 : 생성자 대신 정적 팩터리 메서드를 고려하라

클래스는 생성자와 별도로 정적 팩터리 메서드를 제공할 수 있다.

정적 팩토리 메서드

1. 이름을 가질 수 있다. (반환 객체의 특성 설명 가능)
2. 호출 시마다 새로운 인스턴스를 생성하지 않아도 된다.
3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
   1. 반환할 객체의 클래스를 자유롭게 선택할 수 있는 ‘유연성'을 제공
      1. 팩토리 메서드 이름에 따라 각기 다른 기능의 구현체 생성 가능 (반환 참조 객체는 같다)
   → 이는 인터페이스를 정적 팩토리 메서드 반환 타입으로 사용하느 인터페이스 기반 프레임워크(아이템20)을 만드는 핵심기술
4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
5. **정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다. ****

서비스 제공자 프레임워크 (JDBC)

서비스 제공자 프레임워크에서 서비스의 구현체의 제공을 통제하여 클라이언트를 구현체로부터 분리해준다.

서비스 인터페이스 : 구현체의 정의

제공자 등록 API : 제공자가 구현체를 등록할 때 사용

서비스 접근 API : 서비스의 인스턴스를 얻을 때 사용

→ 클라이이언트는 서비스 접근 API를 사용할 때 원하는 구현체의 조건을 명시하고 반환 받을 수 있다.

정적 팩토리 메서드에서 흔히 사용하는 명명법

• from : 매개 변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드
  Date d = Date.from(instant);
• of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드
  Set<Rank> faceCards = EnumSet.of(jack, queen, king)
• valueOf : from과 of의 더 자세한 버전
  BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE)
• instance 혹은 getInstance(매개변수를 받는 경우) 매개변수로 명시한 인스턴스를 반환하지만 같은 인스턴스임을 보장하진 않음
  StackWalker = luke = StackWalker.getInstance(options)
• create 혹은 newInstance : Instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다
  Object newArray = Array.newInstance(classObject, arrayLen);
• getType : getInstance와 같으나 생성할 클래스가 아닌 다른 클래스에 펙터리 메서드를 정의할 때 쓴다.
  FileStore fs = Files.getFileStore(path)
• newType : newInstance 와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다.
  BufferedReader br = Files.newBufferedReader(path)
• type : getType과 newType의 간결한 버전
  List<Complaint> litany = Collections.list(legacyLitany)

아이템 2: 생성자에 매개변수가 많다면 빌더를 고려해라

정적 팩토리와 생성자는 매개변수가 많을 때 적어야 될게 많고 각각의 매개변수 위치가 어떤 값을 의미하는지 알기 어렵다.

매개변수가 많아지면..

1. 각 위치의 매개변수가 어떤 의미인지 알기 어렵다.
2. 필요한 매개변수에 따라 생성자를 다 따로 만들어줘야만 한다.

→ 클라이언트의 실수를 유발하게 된다.

setter로 필드를 명확히 하면... (자바빈즈패턴)

1. 객체 하나를 만들기 위해서 메서드를 여러개 호출해야하고 모두 호출하기 전까지 **‘일관성'**이 무너진 상태가 된다.
   1. 불변 클래스로 만들 수 없음

대안 ⇒ 점층적 생성자 패턴 + 자바빈즈 패턴의 가독성

[빌터패턴]

1. 클라이언트는 필요한 객체를 직접 만들지 않고 필수 매개변수만을 호출해 빌더 객체를 얻는다.
2. 빌더 객체가 제공하는 세터 메서드로 원하는 매개변수를 설정한다.

// 코드 2-3 빌더 패턴 - 점층적 생성자 패턴과 자바빈즈 패턴의 장점만 취했다. (17~18쪽)
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()에서 이 객체의 생성자에 builder인스턴스를 넘겨줘서 생성하게 된다.

빌더 패턴은 생성 비용이 들지만 매개변수가 점차 늘어나면 관리가 더 어렵다.

→ 매개변수가 많다면 빌더 패턴을 택하자. (간결하고 안전하다)

아이템 3 : private 생성자나 열거 타입으로 싱글턴임을 보증하라

-특징-

1. 싱글톤 : 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다.
2. 클래스를 싱글톤으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워진다.
3. → 싱글턴 인스턴스를 가짜 mock 구현으로 대체할 수 없음

정적 팩터리 방식의 싱글턴

// 코드 3-2 정적 팩터리 방식의 싱글턴 (24쪽)
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();
    }
}
© 2022 GitHub, Inc.

1. 원한다면 유일한 인스턴스가 아닌 호출마다 다른 인스턴스를 넘겨주는 팩터리 메서드로 만들 수 있다.

문제점은 싱글턴 클래스를 직렬화하면 역직렬화 시 새로운 인스턴스가 생긴다는 점이다.

이를 해결하기 위해 readResover메서드를 정의해 싱글턴을 보장한다.

// readResolve 메서드를 정의한다. 역직렬화 시 호출
	private Object readResolve() {
        // 싱글턴을 보장하기 위함!
		return INSTANCE;
	}

열거 타입 방식의 싱글턴이 간결하고 좋다고 한다..

아이템 4 : 인스턴스화를 막으려거든 private 생성자를 사용하라

정적 멤버만 담은 유틸리티 클래스의 경우 인스턴스로 만들어 사용하려는 것이 아니다. (생성자를 만들 필요도 사용할 이유도 없다)

하지만, 생성자를 정의하지 않으면 기본생성자가 자동으로 생성된다.

그러므로 생성자를 private으로 정의해서 클래스의 인스턴스화를 명시적으로 막을 수 있다.

아이템 5 : 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

많은 클래스가 하나 이상의 자원에 의존한다. 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.

클래스가 여러 자원 인스턴스를 지원하도록 인스턴스를 생성할 때 필요한 자원을 넘겨주는 방식을 사용하자 (의존 객체 주입)

• 팩토리를 주입해서 명시한 타입의 하위타입의 어떤 것이든지 생성할 수도 있다.
• 의존 객체 주입은 클래스의 유연성, 재사용성, 테스트 용이성을 개선한다.

아이템 6 : 불필요한 객체 생성을 피하라

똑같은 기능을 제공하는 객체를 사용한다면 매번 생성하지말고 객체 하나를 재사용해라.

매번 새로운 객체를 만드는 것은 비용이다.

재사용이 필요하면 생성자 대신 정적 팩토리 메서드를 사용해 생성된 객체를 재사용하자.

오토박싱은 불필요한 객체 생성을 유발할 수 있다. 조심하자.

private static long sum(){
	Long sum = 0L;
	for(long i = 0; i<= Integer.MAX_VALUE; i++)
			sum +=i;
	return sum;
}
// Long 인스턴스 2^31개 생성하게 됨

요즘에는 JVM 가비지 컬렉터가 최적화가 잘되어있어 객체 풀을 생성하는 것보다 빠르다. 잘못된 반복적 사용은 많은 피해를 불러오므로 조심해서 사용해야한다.

아이템 7 : 다 쓴 객체 참조를 해제하라

가바지 컬렉터는 메모리 관리를 해주지만 개발자가 메모리 관리를 아예 안해도 되는것은 아니다.

package effectivejava.chapter2.item7;
import java.util.*;

// 코드 7-1 메모리 누수가 일어나는 위치는 어디인가? (36쪽)
public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        return elements[--size];
    }

    /**
     * 원소를 위한 공간을 적어도 하나 이상 확보한다.
     * 배열 크기를 늘려야 할 때마다 대략 두 배씩 늘린다.
     */
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }

//    // 코드 7-2 제대로 구현한 pop 메서드 (37쪽)
//    public Object pop() {
//        if (size == 0)
//            throw new EmptyStackException();
//        Object result = elements[--size];
//        elements[size] = null; // 다 쓴 참조 해제
//        return result;
//    }

    public static void main(String[] args) {
        Stack stack = new Stack();
        for (String arg : args)
            stack.push(arg);

        while (true)
            System.err.println(stack.pop());
    }
}

위 코드는 메모리 누수가 발생한다.

스택이 pop() 하고도 여전히 다 쓴 참조를 가지고 있기 때문에 가바지 컬렉터가 메모리를 회수하지 못한다.

이러한 문제를 해결하기 위해서는 단순히 elements[size] = null; 처리만 하면 된다. (참조 해제)

메모리를 직접 관리하는 클래스라면 메모리 누수에 주의하자.

아이템 8 : finalizer와 cleaner 사용을 피하라

두 가지 객체 소멸자.

finalizer

cleaner

• 둘 다 결국 예측할 수 없고 일반적으로 불필요함.
• 즉시 자원을 회수한다는 보장 없음. (회수한다고 예상하고 실행 시 예기치 못한 오류를 만날 수 있음)
• 특히 데이터베이스 락 자원 해제 같은 것을 이 둘에 맡겨 놓으면 시스템 자체가 서서히 멈출 수 있다.
• 보안에취약함
• 성능 하락

아이템 9 : try-finally 보다는 try-with-resources를 사용해라

자원닫기에 안전망으로 finallizer를 사용하기도 하지만 매우 믿을 만 하지 못하다 (이전 아이템)

try-finally를 사용하면 자원을 회수할 순 있다. 하지만 자원이 여러개라면..?

		// 코드 9-2 자원이 둘 이상이면 try-finally 방식은 너무 지저분하다! (47쪽)
    static void copy(String src, String dst) throws IOException {
        InputStream in = new FileInputStream(src);
        try {
            OutputStream out = new FileOutputStream(dst);
            try {
                byte[] buf = new byte[BUFFER_SIZE];
                int n;
                while ((n = in.read(buf)) >= 0)
                    out.write(buf, 0, n);
            } finally {
                out.close();
            }
        } finally {
            in.close();
        }
    }

가독성도 떨어지지만

두 번째 try에서 예외 발생 시 첫번째 예외를 먹어버린다. 이는 추적 내역에 대한 정보가 남지 않아 디버깅을 어렵게 한다.

try-with-resources를 사용하면서 이러한 문제가 해결되었다.

static void copy(String src, String dst) throws IOException{
		try(InputStream in = new FileInputStream(src);
			OutputStream out = new FileOutputStream(dst)) {
			byte[] buf = new byte[BUFFER_SIZE];
			int n;
			while ((n = in.read(buf)) >= 0)
				out.write(buf, 0,n);
		}
	}

try문을 중첩하지 않고 사용할 수 있고 쉽게 자원을 회수할 수 있다.