생성자 대신 정적 팩터리 메서드를 고려하라 - [2장 객체 생성과 파괴(아이템 1)]

  이펙티브 자바를 통해 자바를 조금 더 깊게 공부해보고자 한다. 혼자서 읽고 정리하면서 공부하려고 했지만 생각보다 책이 어렵다. 그래서 백기선 님의 '이펙티브 자바 완벽 공략' 시리즈(총 5부) 강의를 들으면서 공부하려고 한다. 혹시나 해당 블로그에서 이해가 되지 않는 부분이 있다면 백기선 님의 강의를 적극 추천한다.

 

  '2장 객체 생성과 파괴'의 첫 번째 아이템으로 '생성자 대신 정적 팩터리 메서드를 고려하라'라는 것을 소개하고 있다. 클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단으로 public 생성자를 이용하는 방법이 있지만 아래와 같이 정적 팩터리 메서드로도 클래스의 인스턴스를 얻을 수 있다.

public class Order{
    public static Order OrderByStaticFactoryMethod(){
        Order order = new Order();
        return order;
    }
}

  여기서 중요한 점은 public 생성자를 이용하는 방법 대신 무조건 정적 팩터리 메서드를 사용하라는 것은 아니다. 각자의 쓰임새가 있으니 장단점을 이해하고 사용하는 것이 좋다고 말하고 있다. (무작정 public 생성자를 제공하던 습관이 있다면 같이 고쳐나가도록 하자!!) 그러면 이제부터 장점 5가지와 단점 2가지에 대해서 살펴보자.

 

장점 1. 이름을 가질 수 있다.

  public 생성자를 이용하는 경우 class의 이름과 같은 생성자를 사용할 수밖에 없다. 하지만 정적 팩터리 메서드를 사용한다면 반환될 객체의 특성을 쉽게 묘사할 수 있는 이름을 지을 수 있다. 

public class Order{
    private boolean prime;
    private boolean urgent;
    private Product product;
    
    public static Order primeOrder(Product product){
        Order order = new Order();
        this.prime = true;
        order.product = product;
        return order;
    }
    
    public static Order urgentOrder(Product product){
        Order order = new Order();
        order.urgent = true;
        order.product = product;
        return order;
    }
}

 

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

public class Settings{
    private static final Settings SETTINGS = new Settings();
    
    private Settings(){}
    
    public static Settings getInstance(){
        return SETTINGS;
    }
}

  위의 코드에서 알 수 있는 것처럼 정적 팩터리 메서드를 이용하면 계속해서 객체를 생성하는 것을 막을 수 있다. 이 말은 객체 생성을 해당 클래스가 컨트롤한다는 걸로도 볼 수 있다. 이 덕분에 불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다.

 

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

  이 능력은 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 엄청난 유연성을 제공한다. 이는 구체적인 타입을 클라이언트에게 숨길 수 있고, API를 만들 때 이 유연성을 응용하면 구현 클래스를 공개하지 않고도 그 객체를 반환할 수 있어 API를 작게 유지할 수 있다.

public class HelloServiceFactory{
    public static HelloService of(String lang){
        if(lang.equals("ko"){
            return new KoreanHelloService();
        } else {
            return new EnglishHelloService();
        }
    }
}

 

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

  반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다. 예를 들어, EnumSet 클래스는 원소가 64개 이하면 원소들을 long 변수 하나로 관리하는 RegularEnumSet의 인스턴스를, 65개 이상이면 long 배열로 관리하는 JumboEnumSet의 인스턴스를 반환한다.

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

 

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

  이것은 서비스 제공자 프레임워크를 만드는 근간이 된다. 대표적인 서비스 제공자 프레임워크로는 JDBC(Java Database Connectivity)가 있다. 즉, 어떤 데이터베이스를 사용할지 모르는 상태에서 코드를 작성하는 것처럼 사용할 수 있다는 것이다.

 

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

public class Settings{
    private static final Settings SETTINGS = new Settings();
    
    private Settings(){}
    
    public static Settings getInstance(){
        return SETTINGS;
    }
}

  위의 경우처럼 정적 팩터리 메서드만을 제공하면 생성자를 private로 설정한다. 상속을 하려면 public이나 protected 생성자가 필요하므로 이 경우에는 상속을 하지 못하게 된다. (정적 팩터리 메서드를 사용하더라도 생성자를 public으로 사용하는 경우도 있음)

 

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

  생성자처럼 API 설명(JavaDoc)에 명확히 드러나지 않으니 사용자는 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 한다. 생성자가 없고 정적 펙터리 메서드만 있다면 Constructors 부분(JavaDoc에서 제공하는 것)이 없어지고, 만약 메서드가 많아지다면 인스턴스를 생성해주는 메서드를 찾기가 어려워진다. 

  이에 대한 해결책으로 첫 번째는 정적 팩터리 메서드에 흔히 사용하는 명명 방식들을 이용하는 것이다.

• from, of, valueOf, instance 혹은 getInstance, create 혹은 newInstance, getType, newType, type

  두 번째 방식은 아래처럼 문서화를 하는 것이다.

/**
 * 이 클래스의 인스턴스는 #getInstance()를 통해 사용한다.
 * @see #getInstance()
 */

public class Settings{
    private static final Settings SETTINGS = new Settings();
    
    private Settings(){}
    
    public static Settings getInstance(){
        return SETTINGS;
    }
}

 

  이상으로 public 생성자 대신 정적 팩터리 메서드를 사용하여 클라이언트에게 클래스의 인스턴스를 제공하는 방식을 알아보았다.

 

해당 글은 백기선 님의 '이펙티브 자바 완벽 공략'을 수강하고 작성한 것입니다.