쪼리

싱글턴

• 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다.
  • ex) 함수와 같은 무상태 객체, 설계상 유일해야 하는 시스템 컴포넌트
• 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다.
  • 타입을 인터페이스로 정의한 다음 해당 인터페이스를 구현해서 만든 싱글턴이 아니라면 싱글턴 인스턴스를 가짜(mock) 구현으로 대체할 수 없기 때문이다.
• 싱글턴 만드는 방식
  • 두 방식 모두 생성자는 private로 감춰두고, 유일한 인스턴스에 접근할 수 있는 수단으로 public static 멤버를 하나 마련해둔다.

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

• private 생성자는 public static final 필드인 Elvis.INSTANCE를 초기화할 때 한번만 호출된다.
• public, protected 생성자가 없으므로 Elvis 클래스가 초기화될 때 만들어진 인스턴스가 전체 시스템에서 하나뿐임이 보장된다.
  • 예외: 권한이 있는 클라이언트는 리플렉션 api인 AccessibleObject.setAccessible을 사용해 private 생성자를 호출할 수 있다.
  • 이러한 공격을 방어하려면 생성자를 수정하여 두 번째 객체가 생성되려 할 때 예외를 던지도록 한다.
• 장점
  • 해당 클래스가 싱글턴임이 API에 명백히 드러난다
  • public static 필드가 final 이니 절대로 다른 객체를 참조할 수 없다
  • 간결하다

public class Elvis {
    public static final Elvis INSTANCE = new Elvis();
    private Elvis() { ... }

    public void leaveTheBuilding() { ... }
}

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

• Elvis.getInstance는 항상 같은 객체의 참조를 반환하므로 제2의 Elvis 인스턴스는 만들어지지 않다
  • 리플렉션을 통한 예외는 똑같이 적용
• 장점
  • API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다.
  • 정적 팩터리를 제네릭 싱글턴 팩터리(아이템 30)를 만들 수 있다.
  • 정적 팩터리의 메서드 참조를 공급자(supplier)로 사용할 수 있다.
    • Elvis::get Instance → Supplier
  • 이런한 장점들이 굳이 필요하지 않는다면 public 필드 방식이 좋다.

public class Elvis {
         private static final Elvis INSTANCE = new Elvis();
    private Elvis() { }
    public static Elvis getInstance() { return INSTANCE; }

    public void leaveTheBuilding() {...}
}

• 두 가지 방식으로 만든 싱글턴 클래스를 직렬화하는 경우 Serializable을 구현하는 것만으로 부족
  • 모든 인스턴스 필드를 일시적(transient)이라고 선언하고 readResolve 메서드를 제공해야 한다.
  • 그렇지 않으면 직렬화된 인스턴스를 역직렬화할 때 마다 새로운 인스턴스가 생성된다

public Object readResolve() {
    // 진짜 Elvis를 반환하고, 가짜 Elvis는 가비지 컬렉터에 맡긴다.
    return INSTANCE;
  }
}

Singleton은 왜 안티패턴이라 불리는가?

• SOLID 원칙의 대부분은 인터페이스 설계와 관련이 되어있다. 의존성을 concrete class(구현 클래스)가 아닌 Interface에 두면, 실제 concrete class의 구현이 변경되어도 이를 사용한 코드는 큰 영향을 받지 않는다. 그렇기 때문에 SOLID원칙(OCP, LSP, ISP, DIP등)을 지키기 위해서는 인터페이스로 설계를 해야한다.
• 하지만 싱글톤을 이용하는 경우 대부분 인터페이스가 아닌 콘크리트 클래스의 객체를 미리 생성해놓고 정적 메소드를 이용하여 사용하게 된다. 이는 여러 SOLID원칙을 위반할 수 있는 가능성을 열어둠과 동시에, 싱글톤을 사용하는 곳과 싱글톤 클래스 사이에 의존성이 생기게 된다. 클래스 사이에 강한 의존성, 즉 높은 결합이 생기게 되면 수정, 단위테스트의 어려움 등 다양한 문제가 발생한다.

1. private 생성자를 갖고 있어 상속이 불가능하다.

• 싱글톤은 자신만이 객체를 생성할 수 있도록 생성자를 private으로 제한한다. 하지만 상속을 통해 다형성을 적용하기 위해서는 다른 기본생성자가 필요하므로 객체지향의 장점을 적용할 수 없다. 또한 싱글톤을 구현하기 위해서는 객체지향적이지 못한 static 필드와 static 메소드를 사용해야 한다.

2. 테스트하기 힘들다.

• 싱글톤은 테스트하기가 힘드며 테스트 방법에 따라 불가능할 수 있다. 싱글톤은 생성 방식이 제한적이기 때문에 Mock 객체로 대체하기가 어려우며, 동적으로 객체를 주입하기도 힘들다.
• 테스트는 개발의 핵심인데, 테스트 코드를 작성할 수 없다는 것은 큰 단점이 된다.

3. 서버 환경에서는 싱글톤이 1개만 생성됨을 보장하지 못한다.

• 서버에서 클래스 로더를 어떻게 구성하느냐에 따라 싱글톤 클래스임에도 불구하고 1개 이상의 객체가 만들어질 수 있다. 따라서 Java 언어를 이용한 싱글톤 기법은 서버 환경에서 싱글톤이 꼭 보장된다고 볼 수 없다. 또한 여러 개의 JVM에 분산돼서 설치되는 경우에도 독립적으로 객체가 생성된다.
• 생성자를 private하게 두었어도 reflection을 통해 하나 이상의 오브젝트가 만들어질 수 있다. 또한 여러개의 JVM에 분산돼서 설치가 되는 경우에도 각각 독립적으로 오브젝트가 생기기 때문에 싱글톤으로서의 가치가 떨어진다.

4. 전역 상태를 만들 수 있기 때문에 바람직하지 못하다.

• 싱글톤의 스태틱 메소드를 이용하면 언제든지 해당 객체를 사용할 수 있고, 전역 상태(Global State)로 사용되기 쉽다. 아무 객체나 자유롭게 접근하고 수정하며 공유되는 전역 상태는 객체지향 프로그래밍에서 권장되지 않는다.
• 싱글톤 패턴은 객체를 1번 생성하고 재사용할 수 있다는 장점이 있다. 하지만 다른 단점들이 너무 크기 때문에 활용이 쉽지 않았는데, Spring에서는 컨테이너를 통해 직접 객체(빈)들을 싱글톤으로 관리함으로써 객체를 재사용함과 동시에 객체지향스로운 개발을 할 수 있도록 해주었다.

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

• public 필드 방식과 비슷하지만 더 간결하고, 직렬화 가능하고 좋다
• 단, 만들려는 싱글턴이 Enum 외의 클래스를 상속해야 한다면 사용 불가

public enum Elvis {
  INSTANCE;

  public void leaveTheBuilding() {...}
}

참고 출처

• https://ssoco.tistory.com/65

정적 팩터리와 생성자의 제약

• 선택적 매개변수가 많을 때 적절히 대응하기 어려움
• ex) 영양정보를 표현하는 클래스
  • 필수 항목: 1회 내용량, n회 제공량, 1회 제공량당 칼로리
  • 선택 항목: 총 지방, 트랜스지방, 콜레스테롤, 나트륨 등 20가지 이상
  • 대다수 제품은 선택 항목 중 대다수의 값이 0
• 이런 클래스용 생성자 혹은 정적 팩터리는 주로 점층적 생성자 패턴을 사용해왔음

점층적 생성자 패턴

• telescoping constructor pattern
• 필수매개변수 생성자, 필수 + 선택 1 생성자... 형태로 선택 매개변수를 전부 다 받는 생성자까지 늘려가는 방식
• 해당 클래스의 인스턴스를 만들려면 원하는 매개변수를 모두 포함한 생성자 중 가장 짧은 것을 골라 호출
• 단점
  • 매개변수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다

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 NutritionFacts(int servingSize, int servings){
        this(servingSize, servings, 0);
    }

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

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

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

    public NutritionFacts(int servingSize, int servings, int calories,
                          int fat, int sodium, int carbohydrate){
        this.servingSize = servingSize;
        this.servings = servings;
        this.calories = calories;
        this.fat = fat;
        this.sodium = sodium;
        this.carbohydrate = carbohydrate;
    }
}

자바 빈즈 패턴(javaBeans pattern)

• 두번째 대안인 자바빈즈 패턴, 매개변수가 없는 생성자로 객체를 만든 후, 세터 메서드들을 호출해 원하는 매개변수의 값을 설정하는 방식
• 심각한 단점
  • 객체 하나를 만들려면 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성이 무너진 상태에 놓이게 된다
  • 이런 일관성이 무너지는 문제 때문에 클래스를 불변으로 만들 수 없으며 스레드 안정성을 얻으려면 추가 작업이 필요하다.
  • 생성이 끝난 객체를 수동으로 freezing하고 얼리기 전에는 사용할 수 없도록 하기도 한다.
    • 하지만 freeze 메서드를 확실히 호출해줬는지를 컴파일러가 보증 x, 런타임 오류 취약

class NutritionFacts{

    private int servingSize  = -1;  // 필수
    private int servings     = -1;  // 필수
    private int calories     = 0;   // 선택
    private int fat          = 0;   // 선택
    private int sodium       = 0;   // 선택
    private int carbohydrate = 0;   // 선택

    public NutritionFacts() { }

    public void setServingSize(int val) { servingSize = val; }

    public void setServings(int servings) { servings = val; }

    public void setCalories(int calories) { calories = val; }

    public void setFat(int fat) { fat = val; }

    public void setSodium(int sodium) { sodium = val; }

    public void setCarbohydrate(int carbohydrate) { carbohydrate = val; }

NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);

빌더 패턴(Builder pattern)

• 앞의 두가지의 장점을 섞은 세번째 대안

  • 점층적 생성자 패턴의 안정성과 자바 빈즈 패턴의 가독성을 겸비한 패턴

• 클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자(정적 팩토리)를 호출해 빌더 객체를 얻는다

  • 빌더 객체가 제공하는 일종의 세터 메서드들로 원하는 선택 매개변수들을 설정한다
  • 매개변수가 없는 build 메서드를 호출해 필요한(보통은 불변인) 객체를 얻는다.

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

• https://devlog-wjdrbs96.tistory.com/206

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){
            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){
        servingSize  = builder.servingSize;
        servings     = builder.servings;
        calories     = builder.calories;
        fat          = builder.fat;
        sodium       = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}

• 계층적으로 설계된 클래스와 함게 쓰기에 좋다
  • 각 계층의 클래스에 관련 빌더를 멤버로 정의, 추상 클래스는 추상 빌더를, 구체 클래스는 구체 빌더
  • Pizzan.Builder 클래스는 재귀적 타입 한정을 이용하는 제네릭 타입
  • 추상 메서드인 self를 더해 하위 클래스에서는 형변환 하지 않고도 메서드 체이닝 지원
    • self 타입이 없는 자바를 위한 우회 방법을 시뮬레이트한 셀프 타입 관용구라 한다.

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();

                // 하위 클래스는 이 메서드를 오버라이딩하여 this를 반환하도록 해야 한다
        protected abstract T self();
    }

    Pizza(Builder<?> builder){
        toppings = builder.toppings.clone();    // 아이템 50 참조
    }
}

// 뉴욕 피자
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;        
        }

        public NyPizza(Builder builder) {
            super(builder);
            size = builder.size;
        }
    }
}

단점

• 빌더 생성 비용이 문제 될 수도 있다
• 코드가 장황해서 매개변수가 4개 이상은 되어야 값어치를 한다

결론

• 생성자나 정적 팩터리가 처리해야할 매개변수가 많다면 빌더 패턴을 선택하는게 더 낫다.
• 매개변수 중 다수가 필수가 아니거나 같은 타입이면 특히 더 그렇다.
• 빌더는 클라이언트 코드의 가독성이 좋고, 자바빈즈보다 훨씬 안전하다.
• 이런 스타일의 빌더 패턴은 Lombok @Builder로 가능
• https://johngrib.github.io/wiki/design-pattern/builder-pattern/

클라이언트가 클래스의 인스턴스를 얻는 수단

• public 생성자: 전통적인 수단
• 정적 팩터리 메서드(static factory method)
  • 해당 클래스의 인스턴스를 반환하는 정적 메서드
  • 디자인 패턴에서의 팩터리 메서드와 다름

public static Boolean valueOf(boolean b) {
        return b ? Boolean.True : Boolean.False;
}

장점

이름을 가질 수 있다.

• 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하기 어렵다
• BigTnteger(int, int, Random) vs Biginteger.probablePrime()
• 하나의 시그니처로는 생성자를 하나만 만들 수 있다
  • 입력 매개변수들의 순서를 다르게 한 생성자를 새로 추가하는 방식으로 회피할 수 있지만 좋지 않은 방식
  • 정적 팩터리 메서드는 생성자를 정적 팩터리 메서드로 바꾸고 각각의 차이를 잘 드러내는 네이밍

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

• 이로 인해 불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 불필요한 객체 생성 피할 수 있다
• 생성 비용이 큰 같은 객체가 자주 요청되는 상황이라면 성능 향상, 플라이웨이트 패턴과 비슷
• 정적 팩터리 방식의 클래스 == 인스턴스 통제 클래스
  • 즉 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제 가능
• 인스턴스 통제는 플라이웨이트 패턴의 근간이 되며, 열거 타입은 인스턴스가 하나만 만들어짐을 보장한다.

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

• API를 만들 때 이 유연성을 응용하면 구현 클래스를 공개하지 않고도 객체를 반환할 수 있어 api를 작게 유지 가능
• 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크를 만드는 핵심 기술
• 자바8 이전에는 인터페이스에 정적 메서드를 선언할 수 없어서 정적 메서드가 필요하면 동반 클래스를 만들어서 정의하는 것이 관례였다.
  • ex) Collection <> Collections
• 자바8 부터는 동반 클래스를 둘 이유가 별로 없고, 동반 클래스에 두었던 public 정적 멤버들 상당수를 인터페이스 자체에 두면 된다.
  • 하지만 자바9에서는 pirvate 정적 메서드까지 허용하지만 정적 필드와 정적 멤버 클래스는 여전히 public이어야 해서, 별도의 package-private 클래스에 두어야 할 수 도 있다.

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

• 클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없다.
• 반환 타입의 하위 타입이기만 하면 되기 때문이다.

public static <E extends Enum<E>> EnumSet<E> noneOf(Class<E> elementType) {
     Enum<?>[] universe = getUniverse(elementType);
     if (universe == null)
         throw new ClassCastException(elementType + " not an enum");

     if (universe.length <= 64)
         return new RegularEnumSet<>(elementType, universe);
     else
         return new JumboEnumSet<>(elementType, universe);
 }

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

• 이러한 유연함은 서비스 제공자 프레임워크를 만드는 근간이 된다
• 대표적인 예시 JDBC

단점

1. 상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
   • 이 제약은 상속보다 컴포지션을 사용하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 오히려 장점일 수 도 있다.
2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다
   • 생성자처럼 API 설명에 명확히 드러나지 않으니 사용자는 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 한다.

정적 팩터리 메서드에 흔히 사용하는 명명 방식

from

• 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드

Date d = Date.from(instance);

of

• 여러 매겨변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드

Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);

valueOf

• from과 of의 더 자세한 버전

instance / getInstance

• (매개변수를 받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지는 않는다

StackWalker luke = StackWalker.getInstance(options);

create / newInstance

• 위의 내용과 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다

get"Type"

• getInstace와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다.

FileStore fs = Files.getFilsStore(path);

new"Type"

• newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다.

BufferedReader br = Files.newBufferedReader(path);

type

• getType과 newType의 간결한 버전

List<Complaint> litany = Collections.list(legacyLitany);

참고 출처

• https://sysgongbu.tistory.com/95