Java

1 - Creating and Destroying Objects

1.1 - Item1: 생성자 대신 정적 팩터리 메서드를 고려하라

해당 설명에서 정적 팩터리 메서드는 디자인 패턴에서의 팩터리 메서드 패턴을 의미하는 것이 아님!!! 주의!!

‘생성자 대신 정적 팩터리 메서드를 고려하라’ 예를 들어 아래와 같은 경우이다

• NG : BigInteger(int, int, Random) → 다양한 매개 변수에 따라 반환 객체에 대한 특성을 이해하기 어려움
• OK : BigInteger.probablePrime → 반환 객체 특성을 이해하기 쉬움

핵심 정리

정적 팩터리 메서드와 public 생성자는 각각의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋음. 그래도 정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하는 습관이 있다면 고치자!!

장점

1. 이해하기 쉬운 이름을 짓는게 가능.

• 생성자의 이름은 한개(클래스 명) 한정되어 있음.

• 생성자를 구별하는 것은 매개변수 차이 뿐. 결국 사용자는 생성자의 차이를 이해하기 어려움.

  → 정적 팩터리의 경우 이름만 잘 지으면 반환될 객체의 특성을 쉬이 표현 할 수 있다.

2.새로운 오브젝트를 생성할 필요가 없음. 동일한 오브젝트를 사용.

• 이러한 특성으로 불변 클래스(immutable class)는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱해 재활용하는 식으로 불필요한 객체 생성을 피할 수 있음.

  → 생성 비용이 큰 객체가 자주 요청되는 상황에 적용할 경우 성능을 상당히 끌여올려 줄 수 있는 방법!!(Flyweight pattern과 유사한 방법)

• 반복되는 요청에 같은 객체를 반환하는 경우 정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지 통제 할 수 있음

  → 인스턴스 통제(instance-cotrolled) 클래스라 함. 인스턴스를 통제를 하면 클래스를 싱글턴으로 만들 수도 있고, 인스턴스화 불가로 만들 수 있으며, 불변 값 클래스에서 동일한 인스턴스가 단 하나뿐임을 보장할 수 있음.

3. 반환 타입의 하위 타입 객체를 반환할 수 있다.

예를 들어, java.util.Collection에는 emptyList()라는 정적 팩터리 메서드가 있음. 다음과 같은 특징을 가짐.

• emptyList()는 내부 클래스 EmptyList의 인스턴스를 반환 함. 내부 클래스 EmptyList는, public이 아니기 때문에 외부로 부터 감춰짐.
• emptyList()의 반환 타입은 List 인터페이스임.

그래서 Collection의 API는 매우 간결함. 프로그래머는 명시한 인터페이스대로 동작하는 객체를 얻을 것임을 알기에 굳이 알아보지 않아도 됨. 그저 인터페이스의 사용 방법만 알아두면 됨.

4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없음.

5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.(→ 반환 서브타입은 런타임에 정해져도 OK!)

예를 들어, JDBC의 DriverManager.getConnection()의 경우 해당. 결과적으로 API로서의 유연성이 향상 됨.

단점

1. 상속하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.

→ Collection 프레임워크의 유틸리티 구현 클래스들을 상속할 수 없음. 예를 들어, java.util.Collections의 emtpyList()는 EmptyList를 반환되는데 private이기 때문에 EmptyList의 서브 클래스를 만들 수 없음.

2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.

→ 생성자처럼 API 설명에 명확히 드러나지 않아 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 함. 아래와 같은 정적 팩터리 메서드에 사용하는 명명 방식을 이용하여 해당 문제를 완화해줘야 함.

1.2 - Item2: 생성자에 매개변수가 많다면 빌더를 고려하라

핵심 정리

생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는게 더 낫다. 매개변수 중 다수가 필수가 아니거나 같은 타입이면 특히 더 그렇다. 빌더는 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈보다 훨씬 안전하다.

No Good : Telescoping constructor pattern

public class NutritionFacts {
    // 멤버 변수 정의 생략...

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories) {
        this(servingSize, servings, calories, 0);
    }

    // 위와 같은 흐름으로 끊임없이 생성자 정의
}

• 사용자에게 설정하길 원치 않는 매개 변수까지 강제로 값을 지정해야 함.
• 매개 변수 조합에 따라 생성자 수가 많이 늘어 날 수 있음
• 매개 변수가 늘어남에 따라 코드 작성 및 가독성이 저하 됨.
• 타입만 맞으면 컴파일 에러가 발생하지 않기 때문에 같은 타입의 매개변수를 잘못된 순서로 지정할 경우 실수를 눈치 챌 수 없음.
  • 올바른 매개 변수를 입력하고 있는지 계속 체크해야 하는 불편함.

대안1 : JavaBean Pattern

매개 변수가 없는 생성자로 객체를 생성 후, setter 메서드를 호출해 원하는 매개변수의 값을 설정하는 방식!!

No Good : JavaBeans Pattern

public class NutritionFacts {
    // 멤버 변수 정의 생략

    public NutritionFats() {}

    public void setServingSize(int val) { // 생략 }
    public void setServings(int val) { // 생략 }
    public void setCalories(int val) { // 생략 }
    // 멤버 변수의 setter 함수 정의 계속...
}

JavaBeans Pattern 단점

• 객체 하나를 만들려면 메서드를 여러 개 호출해야 함.
• 객체 생성 후, 매개 변수 간 불 일치가 발생할 수 있음. → 객체 생성하기 전에 불일치를 감지해야 함.
• 객체가 완전히 생성되기 전까지 일관성(consistency)이 무너진 상태에 놓이게 됨.
  • setter에서 내부 상태를 변경 할 수 있음. 또한 클래스를 불변(immutable)으로 만들 수 없음. → 스레드 안전성을 얻기 위해 추가 작업 필요.
  • 생성이 끝난 객체를 직접 ‘freezing’ 작업 후 사용하는 방법이 있으나 실무에서는 거의 쓰이지 않음. 또한, freezing 메서드 호출해줬는지 컴파일러가 보증 할 수 없음. → 런타임 오류에 취약

대안2: 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;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        public Builder calories(int val) { 
            this.calories = val; return this;
        }
        public Builder fat(int val) { 
            this.fat= val; return this;
        }
        public Builder sodium(int val) { 
            this.sodium= val; return this;
        }
        public Builder carbohydrate(int val) { 
            this.carbohydrate = val; return this;
        }
        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        this.servingSize  = builder.servingSize;
        this.servings     = builder.servings;
        this.calories     = builder.calories;
        this.fat          = builder.fat;
        this.sodium       = builder.sodium;
        this.carbohydrate = builder.carbohydrate;
    } 
}

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
    calories(100).sodium(35).carbohydrate(27).build();

장점

• 구현하기 쉬움
• 읽기 쉬움
• builder()로 객체 생성하기 전에 매개변수 간 불일치 감지 가능
• 클래스가 계증 구조로 되어 있어도 적용 가능
• API가 유연해짐. 예를 들어 하나의 builder 하나로 여러 객체를 순회하면서 만들수 있고, 빌더에 넘기는 매개 변수에 따라 다른 객체를 만들 수도 있음.

단점

• 객체를 만들려면 빌더부터 만들어야 함. → 빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있음.
• 점층적 생성자 패턴보다는 코드가 길기 때문에 매개변수가 4개 이상은 되어야 값어치를 한다.
• but!! API는 시간이 지날수록 매개변수가 많아지는 경향이 있기 때문에 애초에 빌도로 시작하는 편이 나음.