[이펙티브 자바] 아이템 1: 생성자 대신 정적 팩터리 메서드를 고려하라

new 키워드를 사용한 객체 생성은 자바 개발자에게 가장 익숙한 방법입니다. 하지만 때로는 이 방식이 코드의 의도를 명확하게 드러내지 못하거나, 불필요한 객체를 계속 만들어내는 원인이 되기도 합니다.

이럴 때 생성자의 좋은 대안이 되는 것이 바로 정적 팩터리 메서드(Static Factory Method)입니다. 단순히 new 키워드를 사용하는 대신, 의미 있는 이름을 가진 정적 메서드를 통해 객체를 생성합니다. 이를 통해 가독성과 유연성을 크게 향상시키고, 더 효율적인 메모리 관리를 할 수 있습니다.

 

이번 글에서는 이펙티브 자바 3판 아이템 1 "생성자 대신 정적 팩터리 메서드를 고려하라"의 내용을 기반으로 정적 팩터리 메서드의 5가지 핵심 장점과 단점을 예제 코드와 함께 알아보겠습니다.

 

1. 정적 팩터리 메서드의 5가지 핵심 장점

1-1. 이름을 가질 수 있어 의도를 명확히 표현할 수 있다.

 생성자는 클래스 이름과 동일해야 하고, 매개변수의 타입과 순서로만 서로를 구분합니다. 이 때문에 매개변수만 봐서는 객체가 어떤 상태로 생성되는지 파악하기 어려울 때가 많습니다.

 반면 정적 팩터리 메서드는 자유롭게 이름을 지을 수 있어, 메서드 이름 자체가 문서화 역할을 할 수 있습니다.

복소수(Complex Number)를 생성하는 예로 차이를 이해해봅시다. 

// Before: 생성자 사용 - 의도가 불분명
ComplexNumber c1 = new ComplexNumber(3, 4);  // 좌표인가? 실수부와 허수부인가? 
ComplexNumber c2 = new ComplexNumber(5, Math.PI/4, true);  // 무엇을 의미하는가?

// After: 정적 팩터리 메서드 - 의도가 명확
ComplexNumber c1 = ComplexNumber.ofRectangular(3, 4);  // 직교좌표계
ComplexNumber c2 = ComplexNumber.ofPolar(5, Math.PI/4);  // 극좌표계
ComplexNumber c3 = ComplexNumber.ofImaginary(7);  // 허수

이처럼 ofRectangular, ofPolar 같은 이름은 매개변수의 의미를 완벽하게 설명해 줍니다.

 

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

정적 팩터리 메서드를 사용하면 미리 만들어 둔 인스턴스나 캐싱된 인스턴스를 반환할 수 있습니다. 이 덕분에 불필요한 객체 생성을 피해 성능을 크게 향상시킬 수 있습니다. 특히 생성 비용이 큰 객체나, 반복적으로 동일한 객체가 요청될 때 매우 유용합니다.

가장 대표적인 예는 Boolean.valueOf(boolean) 메서드입니다.

// Boolean.valueOf()는 새로운 객체를 생성하지 않고,
// 미리 생성된 Boolean.TRUE 또는 Boolean.FALSE를 반환
Boolean isTrue1 = Boolean.valueOf(true);
Boolean isTrue2 = Boolean.valueOf(true);

// isTrue1과 isTrue2는 완전히 동일한 인스턴스를 참조
System.out.println(isTrue1 == isTrue2); // 출력: true

이렇게 반복되는 요청에 동일한 객체를 반환하는 식으로 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제 할 수 있는 클래스를 인스턴스 통제(Instance Control) 클래스라고 합니다. 클래스가 생성되는 인스턴스의 수를 통제하여 싱글턴(Singleton) 패턴을 구현하거나, 플라이웨이트(Flyweight) 패턴의 기반을 마련할 수 있습니다.

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

이 능력은 정적 팩터리 메서드가 가진 엄청난 유연성의 핵심입니다. 메서드에 선언된 반환 타입은 인터페이스나 추상 클래스가 될 수 있고, 실제로는 그 하위 타입의 구현체 객체를 자유롭게 선택해서 반환할 수 있습니다.

이러한 유연성 덕분에 우리는 구현 클래스를 외부에 노출하지 않고도 클라이언트에게 객체를 제공할 수 있습니다. 결과적으로, API를 매우 작고 간결하게 유지할 수 있게 됩니다.

 

자바 컬렉션 프레임워크가 이 방식을 잘 활용하고 있습니다.

Java 8 이전: 동반 클래스 Collections 활용

java8 이전에는 인터페이스에 정적 메서드를 선언할 수 없어서, Collections와 같은 별도의 유틸리티 클래스(동반 클래스)를 사용했습니다.

import java.util.*;

public class Java8Style {
    public static void main(String[] args) {
        List<String> list = new ArrayList<>();
        list.add("a");
        list.add("b");
        list.add("c");

        // Collections.unmodifiableList는 수정 불가능한 리스트를 반환
        List<String> unmodifiable = Collections.unmodifiableList(list);

        // 클라이언트는 'List' 인터페이스 타입으로 객체를 다룸
        System.out.println(unmodifiable);
        
        // 실제 구현체의 타입: 내부 클래스인 UnmodifiableRandomAccessList
        // 이 클래스는 외부에 공개되어 있지 않음
        System.out.println(unmodifiable.getClass());
        // 출력: class java.util.Collections$UnmodifiableRandomAccessList
    }
}

 

Java  8 이후 (인터페이스 안에 직접 static 메서드)

자바 8부터 인터페이스에 public 정적 메서드를 선언할 수 있게 되었습니다. 이 덕분에 기존의 동반 클래스가 하던 역할을 인터페이스가 직접 수행할 수 있게 되었습니다. 또한, Java 9에서는 List.of(), Set.of() 와 같은 편리한 컬렉션 정적 팩터리 메서드들이 대거 추가되면서 이 패턴이 더욱 널리 쓰이게 되었습니다.

import java.util.List;

public class Java9Style {
    public static void main(String[] args) {
        // 더 이상 Collections 클래스가 필요 없음
        // List 인터페이스가 직접 불변 리스트를 생성
        List<String> unmodifiable = List.of("a", "b", "c");

        System.out.println(unmodifiable);
        
        // 실제 구현체는 여전히 내부에 감춰진 ImmutableCollections$ListN
        System.out.println(unmodifiable.getClass());
        // 출력: class java.util.ImmutableCollections$ListN
    }
}

왜 구현체를 감출까?

 

• API 단순화: 개발자는 List 인터페이스만 알면 충분합니다. 수십 개의 내부 구현 클래스 이름을 알 필요가 없습니다.
• 구현 교체의 자유: JDK 팀이 나중에 더 효율적인 자료구조를 개발하더라도, 클라이언트 코드에 영향을 주지 않고 내부 구현체를 교체할 수 있습니다.
• 불변성 보장: List.of()로 얻은 리스트는 수정이 불가능합니다. 만약 내부 구현 클래스가 public이라면, 누군가 이를 상속하여 불변 규칙을 깨트릴 수도 있습니다. package-private으로 접근을 막아 이런 위험을 원천 차단합니다.

직접 이 방식을 적용해봅시다.

 

// Shape.java - 공개 API (인터페이스)
public interface Shape {
    double area();

    // 정적 팩터리 메서드
    // 반환 타입은 Shape이지만, 실제로는 Circle 인스턴스를 반환
    static Shape circle(double radius) {
        return new Circle(radius); // Circle은 외부에 공개되지 않은 package-private 클래스
    }

    // 실제로는 Rect 인스턴스를 반환
    static Shape rectangle(double width, double height) {
        return Rect.of(width, height); // 캐싱 기능이 있는 정적 팩터리
    }
}

// Circle.java - 내부 구현체 (package-private)
final class Circle implements Shape {
    private final double radius;

    // 생성자는 package-private으로 외부에서 직접 생성 불가
    Circle(double radius) { this.radius = radius; }

    @Override
    public double area() { return Math.PI * radius * radius; }
}

// Rect.java - 내부 구현체 (package-private)
final class Rect implements Shape {
    private static final Map<String, Rect> CACHE = new HashMap<>();
    private final double width, height;

    private Rect(double width, double height) { this.width = width; this.height = height; }

    // 정적 팩터리 + 캐싱 (플라이웨이트 패턴)
    static Rect of(double width, double height) {
        String key = width + "x" + height;
        return CACHE.computeIfAbsent(key, k -> new Rect(width, height));
    }

    @Override
    public double area() { return width * height; }
}

클라이언트는 Circle이나 Rect 클래스의 존재를 전혀 모른 채 Shape.circle(10)과 같이 인터페이스만으로 객체를 사용하게 됩니다.

 

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

3번 장점의 연장선으로, 정적 팩터리 메서드는 입력값에 따라 반환할 객체의 클래스를 동적으로 결정할 수 있습니다.

EnumSet 클래스가 대표적인 예입니다. EnumSet은 public 생성자 없이 오직 정적 팩터리 메서드만 제공합니다.

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); // 64개 이하면 long 변수 하나로 관리
    else
        return new JumboEnumSet<>(elementType, universe);   // 65개 이상이면 long 배열로 관리
}

클라이언트는 내부적으로 RegularEnumSet이 쓰이는지 JumboEnumSet이 쓰이는지 전혀 알 필요가 없습니다. 그저 EnumSet 인터페이스로만 다루면 됩니다. 만약 나중에 RegularEnumSet의 성능상 이점이 사라져, JDK 팀이 해당 클래스를 삭제하고 항상 JumboEnumSet만 반환하도록 코드를 수정한다 해도 클라이언트에게는 아무런 영향이 없습니다.

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

이 유연함은 서비스 제공자 프레임워크(Service Provider Framework)를 만드는 근간이 됩니다.

대표적인 예는 JDBC(Java Database Connectivity)입니다.

서비스 제공자 프레임워크의 핵심은 서비스의 구현체와 클라이언트를 분리하는 것입니다.

1. 서비스 인터페이스: 구현체의 동작을 정의 (JDBC의 Connection)
2. 제공자 등록 API: 제공자가 자신의 구현체를 등록 (DriverManager.registerDriver)
3. 서비스 접근 API: 클라이언트가 서비스 인스턴스를 얻는 API. 정적 팩터리 메서드. (DriverManager.getConnection)
4. 서비스 제공자 인터페이스: 구현체를 생성하는 팩터리 객체를 설명 (Driver)

클라이언트는 서비스 접근 API(DriverManager.getConnection)를 호출할 때 어떤 데이터베이스(MySQL, Oracle 등)에 연결할지 명시합니다. 그러면 프레임워크는 미리 등록된 제공자(MySQL Driver, Oracle Driver)를 사용해 해당 Connection 구현체 인스턴스를 만들어 반환합니다.

이 구조 덕분에 DriverManager 코드를 작성하는 시점에는 세상에 어떤 Driver 구현체가 존재할지 전혀 알 필요가 없습니다. 이것이 바로 "클래스가 존재하지 않아도 된다"는 말의 의미입니다.

2. 정적 팩터리 메서드 사용의 단점

물론 장점만 있는 것은 아닙니다. 다음과 같은 단점도 존재합니다.

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

Collections의 유틸리티 구현 클래스들이 상속될 수 없도록 설계된 것이 바로 이 때문입니다. 하지만 이는 오히려 상속보다 컴포지션을 사용하도록 유도하고, 불변(Immutable) 타입으로 설계하기 쉽게 만든다는 점에서 장점으로 작용하기도 합니다.

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

생성자는 API 문서 상단에 명확하게 모여있지만, 정적 팩터리 메서드는 다른 일반적인 메서드들 사이에 섞여 있어 눈에 잘 띄지 않을 수 있습니다.

이 단점을 완화하기 위해, API 문서를 충실히 작성하고 널리 알려진 명명 규칙을 따르는 것이 매우 중요합니다.

 

💡 정적 팩터리 메서드 명명 규칙

• from: 매개변수 하나를 받아 해당 타입의 인스턴스를 반환 (형변환)
  • Date d = Date.from(instant);
• of: 여러 매개변수를 받아 인스턴스를 생성 (집계)
  • Set<Rank> cards = EnumSet.of(JACK, QUEEN, KING);
• valueOf: from과 of의 더 자세한 버전
  • BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);
• instance, getInstance: 인스턴스를 반환. 이미 생성된 것을 반환할 수도 있음 (싱글턴)
  • StackWalker luke = StackWalker.getInstance(options);
• create, newInstance: 매번 새로운 인스턴스를 생성하여 반환함을 보장
  • Object newArr = Array.newInstance(classObject, arrayLen);
• getType: 다른 클래스에 팩터리 메서드를 정의할 때 사용. getInstance와 유사.
  • FileStore fs = Files.getFileStore(path);
• newType: 다른 클래스에 팩터리 메서드를 정의할 때 사용. newInstance와 유사.
  • BufferedReader br = Files.newBufferedReader(path);

---

정리

정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니, 상대적인 장단점을 이해하고 사용하는 것이 좋습니다. 하지만 많은 경우 정적 팩터리 메서드가 더 나은 선택이 될 수 있으므로, 무작정 public 생성자를 사용하는 것은 지양하는 것이 좋습니다.