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

💬 이팩티브자바 챕터 1을 읽고 정리한 글입니다.

---

 

✔️ 정적 팩터리 메서드란?

우테코 미션을 진행하면서, 정적 팩터리 메서드를 정말 많이 사용하였다. 정적 팩터리 메서드란, 클래스의 인스턴스를 반환하는 정적 메서드이다. 즉, 생성자 역할을 하면서도 객체를 생성하기 전에 1차적으로 통과하는 '문' 같은 존재라고도 볼 수 있다. 정적 팩터리 메서드를 사용하면 어떤 점이 좋을까?

 

💬 동일한 시그니처라도, 이름에 따라 새롭게 생성해줄 수 있다.

어느 날, 우테코에 크루 신청을 하기 위해 신청서를 작성하고 있었다. 이때, 닉네임을 아직 정하지 못한 크루는 이름과 나이, 그리고 과정만을 가지고 크루를 신청하고 싶었다.

public class Crew {
    private String name;
    private String nickname;
    private int age;
    private Course course;

    public Crew(final String name,  final int age, final Course course) {
        this.name = name;
        this.age = age;
        this.course = course;
    }
}

그러나, 또 개인정보 보호에 굉장히 민감했던 한 크루는 나이는 알려주고 싶지 않아서 닉네임과 이름, 그리고 과정만 받아서 크루 신처엇를 내려고 한다.

public class Crew {
    private String name;
    private String nickname;
    private int age;
    private Course course;

    public Crew(final String name, final int age, final Course course) {
        this.name = name;
        this.age = age;
        this.course = course;
    }

    public Crew(final String name, final String nickname, final Course course) {
        this.name = name;
        this.nickname = nickname;
        this.course = course;
    }
}

그러다, 또 어떤 크루는 닉네임, 나이, 그리고 과정만을 가지고 크루 신청서를 내려고 한다. 이때, 한 가지 문제가 발생한다.

public class Crew {
    private String name;
    private String nickname;
    private int age;
    private Course course;

    // ERROR 
    public Crew(final String name, final int age, final Course course) {
        this.name = name;
        this.age = age;
        this.course = course;
    }

    // ERROR
    public Crew(final String nickname, final int age, final Course course) {
        this.nickname = nickname;
        this.age = age;
        this.course = course;
    }

    public Crew(final String name, final String nickname, final Course course) {
        this.name = name;
        this.nickname = nickname;
        this.course = course;
    }
}

바로, 동일한 시그니처를 가진 생성자를 또 선언할 수 없는 것이다. 그러나, 정적 팩터리 메서드를 활용하면 이러한 문제를 해소할 수 있다. 이때, 각각의 차이를 잘 드러내는 이름을 지어준다면 더 베스트이다.

public class Crew {
    private String name;
    private String nickname;
    private int age;
    private Course course;

    private Crew() {
        // 외부에서 인스턴스화 막기
    }

    public static Crew createByName(final String name, final int age, final Course course) {
        Crew crew = new Crew();
        crew.name = name;
        crew.age = age;
        crew.course = course;
        return crew;
    }

    public static Crew createByNickname(final String nickname, final int age, final Course course) {
        Crew crew = new Crew();
        crew.nickname = nickname;
        crew.age = age;
        crew.course = course;
        return crew;
    }
}

위와 같이 메서드명에 따라 원하는 필드를 주입받아 새로운 객체를 생성해줄 수 있으며, 동일한 시그니처를 가지더라도 원하는 특성을 가지는 객체를 만들어낼 수 있게 된다. (생성자를 통해 해결하려고 했다면, 아마 flag를 두거나 인자로 다 받아서 처리해야 하기 때문에 코드가 매우 복잡하고 더러워졌을 것이다 🥲)

---

 

💬 호출될 때마다 인스턴스를 생성하지 않아도 된다.

생성자를 사용하게 되면, new를 통해 계속 인스턴스를 생성하게 되기 때문에 꼭 새로운 인스턴스가 필요한 상황이 아니라면 낭비가 될 수도 있다. 이때, 정적 팩터리 메서드를 활용하면 인스턴스를 미리 만들어 두거나, 혹은 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다. (ex. 플라이웨이트 패턴) 이는, 반복되는 요청에 대해 같은 객체를 반환하기 때문에, 인스턴스에 대해 통제가 가능해진다.

 

 

💡 플라이웨이트 패턴이란?

: 인스턴스를 가능한만큼 공유하여, new를 통한 메모리 낭비를 줄이는 방식이다.

map을 통해서 관리를 진행하고, 하나의 특성을 key로 잡아, 해당 key가 존재한다면 이미 생성한 인스턴스를 반환하고, 아니라면 새로 생성해주는 방법이다. 다만, 이 방법은 인스턴스가 매우 많이 필요하면서도 사용되는 횟수가 많고, 모두 동일한 로직으로 제어가 가능할 때 사용하는 것이 좋다.

 

이는, 객체들을 공유하고 있기 때문에, 서로 다른 객체이더라도 동일성을 어떤 식으로 체크하는지에 따라 동일한 객체라고 받아들일 수 있기 때문에, 웬만하면 공유 객체들을 사용하더라도 문제가 없는 경우 사용해야 한다.

플라이웨이트 패턴을 사용한 대표적인 예시는, 자바의 래퍼 클래스들의 valueOf() 메서드를 예시로 들 수 있다. 

// Boolean.java
public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);

public static Boolean valueOf(boolean b) {
    return (b ? TRUE : FALSE);
}

Boolean의 경우 true, false만 가지고 있기 때문에 인자로 들어온 값에 따라서 미리 선언된 TRUE, FALSE 인스턴스를 반환하게 된다. 즉, 생성한 인스턴스를 캐싱하여 반환해주는 형태인 것이다.

그래서 대부분의 wrapper 클래스의 경우, new를 통해 객체를 생성하지 않고 valueOf로 생성하는 것을 권장한다. 상단에 주석을 보면, 이 생성자는 굉장히 부적절하고 '정적 팩터리' valueOf을 통해서 생성하라고 적힌 것을 볼 수 있다 ☺️

---

 

💬 반환 타입의 하위 타입 객체를 반환하도록 제어할 수 있다.

class Circle extends Shape {
    @Override
    public String hello() {
        return "I'm Circle!";
    }
}

Circle이라는 자식 클래스가 있다. 이는 Shape라는 부모 클래스를 상속받은 자식 클래스이다.

class Shape {
    public String hello() {
        return "I'm Shape!";
    }

    public static Shape create() {
        return new Circle();
    }
}

이때, Shape의 정적 메서드에서 create를 호출했을 때 내부적으로 Circle()이라는 구현체를 반환하기 때문에 외부에서 해당 create() 메서드를 접근했을 때 구현 클래스에 대한 정보가 없더라도 해당 객체를 반환할 수 있게 된다.

public static void main(String[] args) throws IOException {
        Shape shape = Shape.create();
        System.out.println(shape.hello()); // I'm circle!
}

위 예제에서는 간단하게 클래스 간 상속 관계를 사용하였지만, 인터페이스에서도 마찬가지이다. 인터페이스를 반환타입으로 사용하여 구현 객체에 대해 API에 노출을 하지 않아도 되고,  내부적인 구현 로직이 숨겨진다는 장점도 존재한다. (보통, 인터페이스가 반환 타입이라는 것은 해당 인터페이스를 구현한 클래스의 인스턴스를 리턴함을 의미한다.)

 

💡 구현 로직이 숨겨지는 것이 왜 장점일까?

추상화의 장점을 생각해보면 좋다. 외부에서 접근할 때 구현 클래스의 코드가 나타나는 것은 별로 좋지 않은 구조이다. 만약 구현 클래스가 변경될 경우, 해당 외부 접근 코드도 함께 수정되어야 하기 때문에 영향이 커지기 때문이다. 반면, 인터페이스를 리턴하게 되면 내부의 구현 클래스가 변경되더라도 외부에서는 항상 인터페이스만 바라보고 있기 때문에 독립적으로 내부 구현체에 대해 변경할 수 있으며, 복잡도가 떨어지고 유연한 설계가 가능하게 된다!

 

또한, 반환값이 인터페이스라면 정적 팩터리를 작성하는 시점에는 오직 '인터페이스'만을 반환하도록 하면 되기 때문에, 별도의 구현 클래스를 생성하지 않더라도 개발이 계속 가능하게 된다. 이를 이용한 게 JDBC 같은 서비스 제공자 프레임 워크이며, 클라이언트가 구현된 서비스를 이용하더라도 내부적으로 어떤 클래스가 있는지 몰라도 된다! 

// DriverManager.java
public static Connection getConnection(String url,
	java.util.Properties info) throws SQLException {

    return (getConnection(url, info, Reflection.getCallerClass()));
}

코드가 복잡하기 때문에 길게는 안 다루지만, DriverManager라는 클래스에서 Connection 정보를 얻을 수 있으며, 프로퍼티 정보에 따라 그에 맞는 구현체를 반환하게 된다.

 

---

✔️ 정적 팩터리 메서드의 단점

물론, 당연히 이러한 정적 팩터리 메서드에도 단점은 존재한다. 기본적으로 정적 팩터리 메서드를 만든다는 것은 생성자를 private로 만들겠다는 의미이다. 그러나, 상속을 위해서는 public / protected 생성자가 필요하기 때문에, 하위 클래스를 만들 수 없다.

이를 해결하기 위해서는 protected / default 생성자를 구현하거나, 혹은 상속받지 않는 것도 하나의 방법이다. (실제로, 요즘은 상속받지 않는 것이 꽤 트렌드이다. (코틀린의 경우 상속 금지가 기본이니까)

 

또한, 명확하게 드러나지 않기 때문에 프로그래머가 찾기 어렵다는 단점도 존재한다. 그러나, 이는 정적 팩터리 메서드에 대한 네이밍을 잘 지킨다면 해결될 수 있기 때문에 네이밍을 잘하는 것이 중요하다! 🥹

 

컨벤션	사용법	예시
from	매개변수를 하나 받아서, 해당 타입의 인스턴스 반환	Date date = Date.from(instant)
of	여러 매개변수를 받아서 적합합 타입의 인스턴스 반환	Set<Rank> faceCards = 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 newArray = Array.newInstance(classObject, arrayLen)
getType	getInstance와 동일하지만, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 사용한다. 여기서 들어가는 Type은 팩터리 메서드가 반활할 객체의 타입을 의미한다.	FileStore fs = Files.getFileStore(path);
newType	newInstance와 같지만, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드 정의 시 사용한다 (getType과 비슷)	BufferedReader br = Files.newBufferedReader(path);
type	getType, newType의 간결한 버전	List<Complain> litany = Collections.list(legacyLitany)