쏘니의 개발블로그

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

싱글톤을 만드는 방법고 어떻게 만드는 것이 효율적일지 볼 수 있다.

싱글톤이란

인스턴스를 오직 하나만 생성할 수 있는 클래스이다.

싱글턴을 만드는 방식

생성자는 private 으로 감춰두고, 인스턴스에 접근할 수 있는 수단으로 public static 멤버를 만든다.

방법 1. public static 멤버가 FInal 필드인 방식

public class Single {
	public static final Single INTANCE = new Single();
    private Single() { ... }
    
    public void 메소드동작() {
     ...
    }
}

설명 : private 생성자는 PUBLIC Static final 필드인 Single.INSTANCE 를 초기화할 때 한번만 호출된다.

public 이나 Protected 생성자가 없으므로 Single 클래스가 초기화될때 만들어진 인스턴스가 전체 시스템에서 하나뿐인게 보장된다.

혹여나 리플랙션 API 로 private 생성자를 호출할 수 있지만, 이러한 것도 방어하려면 생성자를 수정하여 두번째 객체가 생성되려 할때 예외를 던지게 하면 된다.

장점 :

1) 해당 클래스가 싱글턴임을 API 를 보고 바로 알 수 있다.

public static 필드가 final 이라 절대로 다른 객체를 참조 할 수 없다.

2) 간결함

2. 정적 팩터리 메서드를 public static 멤버로 제공하자.

public class Single {
	private static final Single INTANCE = new Single();
    private Single() { ... }
    
    public static Single getIntance() { return INTANCE; }
    
    public void 메소드() {
    	...
    }
}

설명 : Single.getIntance 는 항상 같은 객체의 참조를 반환하므로 하나의 객체만 생성된다.

장점 :

1) 개발자의 의도가 바뀌면 API를 바꾸지 않고도 싱글톤이 아니게 변경 가능하다.

팩토리 메소드가 호출하는 스레드별로 다른 인스턴스를 넘겨주게 할 수 있다.

2) 또한 원한다면 정적 팩터리를 제네릭 싱글턴 팩터리로 만들수 있다.

3) 정적 팩터리의 메소드 참조를 공급자(supplier) 로 사용할 수 있다. 

Single::getIntance 를 Supplier<Single> 로 사용하는 방법이다.

위의 장점들이 필요하지 않다면 방법1 public 필드 방식이 좋다.

둘 중 하나의 방식으로 만든 싱글턴 클래스를 직렬화하려면 Serializable 을 구현한다고 선언하는 것만으로 부족하다.

모든 인스턴스 필드를 transient 라고 선언하고 readResolbe 메소드를 제공해야 한다.

이렇게 하지 않으면 직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 만들어진다.

// 싱글톤임을 보장해주는 READREsolve 메소드
private Object readResolve() {
	// '진짜' Single 를 반환하고 '가짜' 객체 Single 는 가비지 컬렉터에 맡긴다.
    return INSTANCE;
}

3. 원소가 하나인 열거 타입을 선언하자

public enum Single {
	INSTANCE;
    
    public void 메소드() {
    	...
    }
}

설명 :

1) 방법 1 Public 필드 방식과 비슷하지만 더 간결하고 추가 노력 없이 직렬화 할 수 있다.

2) 또한 복잡한 직렬화 상황이나 리플렉션에서도 인스턴스가 추가되는 것을 막아준다.

대부분의 상황에서는 원소가 하나뿐인 ENUM 타입이 싱글턴을 만드는 가장 좋은 방법이다.

대신 싱글톤이 Enum 외의 클래스를 상속해야 하면 이 방법은 사용불가 (열거 타입이 다른 인터페이스를 구현하도록 선언할 수는 있다.) 

-> 책에서의 이 말이 이해가 안감........

점층적 생성자 패턴도 쓸 수는 있지만, 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다.

setter 를 통해서 객체값 세팅(자바빈즈 패턴) 에서는 객체 하나를 만들기 위해 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성이 무너지게 된다.

자바빈즈 패턴에서는 클래스를 불변으로 만들 수 없다.

이러한 객체 불변과 점층적 생성자 패턴의 대안은 빌더 패턴이다.

빌더는 생성할 클래스 안에 정적 멤버 클래스로 만들어두는게 보통이다.

// 코드 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();
    }
}

빌더의 세터 메서드들은 빌더 자신을 반환하기 때문에 연쇄적으로 호출 할 수 있다. 이런 방식을 플루언트 API 혹은 메서드 연쇄(method chaning) 라고 한다.

빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기에 좋다.

추상 클래스는 추상빌더를 구체 클래스는 구체 빌더를 갖게 한다,

// 코드 2-4 계층적으로 설계된 클래스와 잘 어울리는 빌더 패턴 (19쪽)

// 참고: 여기서 사용한 '시뮬레이트한 셀프 타입(simulated self-type)' 관용구는
// 빌더뿐 아니라 임의의 유동적인 계층구조를 허용한다.

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 참조
    }
}

추상메서드인 self 를 더해 하위 클래스에서는 형변환하지 않고드 메서드 연쇄를 지원할 수 있다.

// 코드 2-5 뉴욕 피자 - 계층적 빌더를 활용한 하위 클래스 (20쪽)
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 + "로 토핑한 뉴욕 피자";
    }
}

// 코드 2-6 칼초네 피자 - 계층적 빌더를 활용한 하위 클래스 (20~21쪽)
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 ? "안" : "바깥");
    }
}

각각의 Calzone 과 NyPizza Builder 는 NyPizza 와 Calzone 를 반환한다. 하위 클래스의 메서드가 상위 클래스의 메서드가 정의한 반환 타입이 아닌 그 하위 타입을 반환하는 기능을 공변 반환 타이핑(covariant return typing) 이라 한다.

이 기능을 이용하면 클라이언트가 형변환에 신경 쓰지 않고도 빌더를 사용할 수 있다.

2장. 객체 생성과 파괴

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

정적팩터리 메서드가 생성자보다 좋은 장점 다섯가지

1. 이름을 가질수 있다.

생성자에 넘기는 매개변수와 생성자 자체로는 반환되는 객체의 특성을 알 수 가 없다. 

BigInteger (int, int, Random) vs BigInteger.probablePrime 중에 값이 소수인 BigInteger 를 반환하는 것을 알기 쉽다.

2. 호출될 떄마다 인스턴스를 새로 생성하지는 않아도 된다.

Boolean.valueOf(boolean) 메서드는 객체를 생성하지 않는다. 

반복되는 요청에 같은 객체를 반환하는 식으로 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제 가능. instance-controlled (인스턴스 통제)

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

API를 만들 때 이 유연성을 응용하면 구현 클래스를 공개하지 않아도 그 객체를 반환할 수 있어 API를 작게 유지할 수 있다.

자바 8 부터 인터페이스를 정적 메소드로 선언 가능하다.

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

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

5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

이런 점은 서비스 제공자 프레임워크(service provider framework)를 만드는 토대가 된다. 대표적인 예시로는 JDBC. 

서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 구성.

- 구현체의 동작을 정의하는 서비스 인터페이스

- 제공자가 구현체를 등록 할 때 사용하는 제공자 등록 API

- 클라이언트가 서비스의 인스턴스를 얻을 떄 사용하는 접근 API

여기서 서비스 접근 API 가 유연한 정적 팩터리 이다.

서비스 제공자 API 인터페이스가 없다면 각 구현체를 인스턴스로 만들 떄 리플렉션을 사용해야 한다.

JDBC 에서는 Connectin 이 서비스 인터페이스 역할을, DriverManager.registerDriver 가 제공자 등록 API 역할.

DriverManager.getConnection 이 서비스 접근 API 역할을, Driver 가 서비스 제공자 인터페이스 역할을 수행한다.

여기서 서비스 접근 API 는 공급자가 제공하는 것보다 더 풍부한 서비스 인터페이스를 클라이언트에 반환할 수 있다.

단점

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

2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다. 네이밍으로 해결

• from: 매개변수를 받아 해당 타입의 인스턴스를 반환하는 형변환 메서드 
  ex) Date d = Date.from(instant)
• of: 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드 
  ex) Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING)
• valueOf : from 과 of 의 더 자세한 버전 -                                                                                                                                   ex) BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE)
• instance 혹은 getInstance : 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장 하지 않는다.                              ex) StackerWaker luke = StackWalker.gtInstance(options)
• create 혹은 newInstance : 매번 새로운 인스턴스를 생성해 반환                                                                                                  ex) Object newArray = Array.newInstance(classObject, arrayLen)
• getType : 생성할 클래스가아닌 다른 클래스에 정의할 때 사용.
  ex) FileStore fs = Files.getFileStore(path)
• newType : 생성할 클래스가 아닌 다른 클래스에 정의할 때 사용 
  ex) BufferedReader br = Files.newBufferedReader(path)
• type: getType 과 newType 의 축약 
  ex) List<Company> litnay = Collection.list(legacyLitany)

정리

정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하자.

그래도 정적팩터리를 사용하는게 유리한 경우가 더 많으므로, 무조건 생성자를 제공하는 습관은 버리자.

이펙티브 자바 3판입니다.

이 책은 자바 중급 이상의 책이고, 자바 개발자들이 한번쯤 읽어봐야 할 책으로 중급개발자로 나아가기 위한 책이라고 많이 들어서 정주행 하려고 합니다.

자바 8에 대한 이해도를 높이기 위해서도 이 책을 추천할 만한 책인 것 같습니다.

책의 예제 코드입니다.

https://github.com/WegraLee/effective-java-3e-source-code

책 서평에 적혀 있는 공식 강의입니다.

백기선님의 유튜브 강의입니다. 정말 대단하신 분이네요. 인프런 강의도 엄청 많은데,,,,,

https://www.youtube.com/watch?v=X7RXP6EI-5E&list=PLfI752FpVCS8e5ACdi5dpwLdlVkn0QgJJ