2-1 생성자를 대신하는 정적 팩토리 메서드

# 개요

API를 사용하는 개발자를 사용자라고 칭한다.

API를 사용하는 클래스를 [그 API의 클라이언트]라고 칭한다.

 

#1. 생성자를 대신하는 정적 팩토리 메서드

객체를 생성하는 메서드를 Factory Method라고 한다.

[✔ 생성자를 이용해서 객체를 만드는것] 대신에  [✔ Static Factory Method를 사용하는 방법]의 사용을 고려하자.

 

장점

• 이름을 가질 수 있다.
• 호출될 때마다 인스턴스를 새로 생성하지 않을 수도 있다.
• 반환 타입의 하위 타입 객체를 반환할 수도 있다.
• 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수도 있다.
• 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

단점

• 상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들수 없다. (불변 타입으로 만들경우 오히려 장점이 될수 있다)
• 정적 팩터리 메서드는 프로그래머가 확인작업이 필요하다.(주석을 달자)

주의사항

• 생성자만 있어도 충분한 클래스에 무조건적으로 팩토리 메서드를 적용하는 바보 짓은 하지말자.
• 메서드 이름(of, from...)에 대한 규약이 있는게 아니라서, 팩토리 메서드 기능에 대한 확실한 정의가 필요하다.

📑 생성자 오버로딩으로 구현하면 안되나요? 왜 굳이 Build()를 사용해야하나요?)

// 점층적 생성자 패턴 - 더 많은 인자 개수에 잘 적응하지 못한다.
public class NutritionFacts {
  private final int servingSize;  // (mL)             필수
  private final int servings;     // (per container)  필수
  private final int calories;     //                  선택
  private final int fat;          // (g)              선택
  private final int sodium;       // (mg)             선택
  private final int carbohydrate; // (g)              선택

  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;
  }
}

 

불편하다. 그래서 자바 Bean 에서는 아래와 같이 변경하였다.

// 자바빈 패턴 - 일관성 훼손이 가능하고, 항상 변경 가능하다.
public 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() { }
  // 설정자(setter)
  public void setServingSize(int val) { servingSize = val; }
  public void setServings(int val) { servings = val; }
  public void setCalories(int val) { calories = val; }
  public void setFat(int val) { fat = val; }
  public void setSodium(int val) { sodium = val; }
  public void setCarbohydrate(int val) { carbohydrate = val; }
}

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

 

자바 Bean에서 사용한 방법은 빌더 패턴과 유사하다.

하지만 객체생성이후, Setter로 값을 설정하는 방법은 데이터의 일관성이 깨질 수 있다.

그래서 아래와 같이 개선한 방법이 바로 정적 팩토리 메서드, 내부 클래스 Builder를 사용하는 패턴이다.

1. 필수 인자들을 생성자에(또는 정적 팩터리 메서드에) 전부 전달하여 빌더 객체(Builder object)를 만든다.
2. 빌더 객체에 정의된 설정 메서드들을 호출하여 선택적 인자들을 추가해 나간다.
3. 마지막으로 아무런 인자 없이 build 메서드를 호출하여 변경 불가능(immutable) 객체를 만드는 것이다.

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

// 빌더 패턴
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 Item1 of(String name, String email) {
  return Item1.builder()
    .name(name)
    .email(email)
    .build();
}

public class Main{
    public void main(){
        //from: 매개변수가 1개일 경우,
        Dog dog = Dog.from(name);
        
        //of: 여러 매개변수를 사용할 경우,
        Dog dog = Dog.of(name, age);
        
        //valueOf: from, of 보다 자세한 버전.
        Dog dog = Dog.valueOf(name, age);
        
        //getInstance: 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지 않음.
        Dog dog = getInstance(age);
        
        //newInstance: 매번 새로운 인스턴스를 반환.
        Dog dog = Dog.newIncetance(name, age);
        
        //getType: 다른 클래스의 팩터리 메서드를 사용할 경우.
        Dog dog = Animal.getDog(name);
        
        //newType: 다른 클래스의 팩터리 메서드를 사용, 매번 새로운 인스턴스를 반환.
        Dog dog = Animal.newDog(name);
        
        //getType, newType의 간결한 버전.
        Dog dog = Animal.dog(age);
    }
}

 

@ 장점1-메서드의 이름을 가질 수 있다.

메서드의 이름을 통해 더 읽기 좋은 코드를 작성할 수 있다.

생성자와 다르게 메서드의 이름이 있으므로 타입이 완전히 같더라도 다른 동작을 하는 팩토리 메서드를 만들 수 있다.

 

@ 장점2-호출될 때 마다 인스턴스를 새로 생성하지 않아도 된다.

생성자를 Private로 막아놓고 인스턴스를 재사용할 수 있게 만든다. 싱글톤 객체로 만들 수 있다.

정적 팩토리 방식의 클래스는 인스턴스의 생명주기를 통제할 수 있다.

 

@ 장점3,4-생성자를 막음으로서 인터페이스처럼 활용이 가능하다.

생성자 역할을 대신해주는 팩토리 메서드가 생김으로서, 인터페이스처럼 사용이 가능하다.

자신을 생성하여 반환할 필요가 없다. 객체를 인터페이스처럼 만들어놓고 하위타입, 자식객체(구현체)를 반환해도 된다.

➡ 구현클래스를 공개하지 않고도 객체를 반환할 수 있어 공개된 API를 제한하는 효과가 있다.

// Java8이전에는 인터페이스 내에서 Static, Default 메서드를 가질 수 없었다.
// 그래서 Collection을 아래와 같이 팩토리 메서드로 구현하였음.
public class Collections {
    // 인스턴스 생성불가
    private Collections() {
    }

    // 정적 펙토리 메서드
    public static <T> List<T> unmodifiableList(List<? extends T> list) {
        return (list instanceof RandomAccess ?
                new UnmodifiableRandomAccessList<>(list) :
                new UnmodifiableList<>(list));
    }
}

// 구현체 : non-public 이다. 상위 타입의 팩토리 메서드를 거치지 않고는 만들 수 없다.
class UnmodifiableList<E> extends UnmodifiableCollection<E> implements List<E> {
        ...
}

 

➡ Java8 에서 interface 안에서 deafult, static 메서드의 사용이 가능해지면서, 조금 더 편하게 구현할 수 있게 되었다.

public interface TestInterface {

    void print();

    static void getLowerType() {
        TestExtendClass testExtendClass = new TestExtendClass();
        testExtendClass.print();
    }
}

// package-private으로 해당 구현체를 생성할 수 없다. 상위 타입인 인터페이스에서 생성하여 사용한다.
class TestImplementsClass implements TestInterface {

    @Override
    public void print() {
        System.out.println("print test");
    }
}

 

@ 장점4- 사용하기 전까지 반환할 객체의 클래스가 존재하지 않아도 된다.

생성자를 만들어두지 않고 사용하는 시점에 객체를 생성해서 불필요한 객체의 생성을 막는다.

String s = new String("hello"); // 실행될 때 마다 객체를 새로 만든다.
String s = "hello" // 한 객체(상수)를 두고 재사용한다.

boolean isValue = str // 미리 만들어두는 방식
Boolean.valueOf(str) // 팩토리 메서드 방식

팩토리 메서드로 싱글톤과 비슷하게 구현할 수 있다. ➡ 완벽한 싱글톤을 원한다면 아래 링크를 참고하자.

2021.09.10 - [Backend/디자인패턴] - Singleton (싱글톤 패턴)

Singleton (싱글톤 패턴)

public class Person {
  private final Date birthDate;
  // 다른 필드와 메서드, 생성자는 생략

  // 이렇게 하면 안 된다!
  public boolean isBabyBoomer() {
    // 생성 비용이 높은 Date 객체를 쓸데없이 생성한다
    Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
    gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
    Date boomStart = gmtCal.getTime();
    gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
    Date boomEnd = gmtCal.getTime();
    return birthDate.compareTo(boomStart) >= 0 && birthDate.compareTo(boomEnd) < 0;
  }
}

public class Person {
  private final Date birthDate;
  // 다른 필드와 메서드, 생성자는 생략

  static {
    Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
    gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
    BOOM_START = gmtCal.getTime();
    gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
    BOOM_END = gmtCal.getTime();
  }

  public boolean isBabyBoomer() {
    return birthDate.compareTo(BOOM_START) >= 0 && birthDate.compareTo(BOOM_END) < 0;
  }
}

 

---

# 실제 서비스에서의 장단점

장점

• 매개변수가 많을 경우, 코드를 읽고 이해하기 매우 쉽다.
• setter를 이용한 방식(자바빈즈)의 경우, 객체의 불변성을 보장할 수가 없다. public으로 setter가 공개 되어 있기 때문이다. 이에 비해, 빌더 패턴을 사용할 경우 불변 객체로 만들기 쉽다.
• 빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기에 좋다.

 

단점

• 빌더 패턴은 코드량이 많다. : @builder는 어떤가, API는 시간이 지날수록 매개변수가 많아 질것이다.
• 빌더클래스를 생성해야한다 : 성능에 매우 민감하다면 문제가 될수도 있다. 사용하지도 않는 곳에 빌더를 넣지말자.