아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라

클라이언트🗣🔊 "야,,, 클래스의 인스턴스 내놔👊" 할 때, 주는 방법

 

1. public으로 열린 생성자 호출 (전통적🏮)
2. 정적 팩터리 메서드

➡️ 클래스는 클라이언트에게 public 생성자, 정적 팩토리 메서드를 제공할 수 있다. 즉, 인스턴스를 생성하는 방법이 2가지가 된 것 ❣️

 

책의 저자는 '정적 팩터리 메서드와 팩터리 메서드는 다르다!' 고 했다. 이름도 비슷한데, 뭐가 다른 걸까? 생각해봤다.

누군가... 팩터리 메서드에 대해 이렇게 정의했다.
Factory Methodis a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.

---

팩토리 메소드 패턴(Factory Method Pattern)은 객체를 생성하기 위해 인터페이스를 만듭니다. 어떤 클래스의 인스턴스를 만들지를 서브클래스에서 결정하도록 합니다. 팩토리 메소드를 이용하면 인스턴스를 만드는 일을 서브클래스로 미룰 수 있습니다.

팩터리 메서드는 상속에 의존하는 디자인 패턴이다. 하지만, static 즉, 정적 팩터리 메서드를 이용하면 더 이상 하위 클래스에서 확장할 수 없으므로 팩터리 메서드 패턴의 목적에 어긋난다. 이 부분을 차이라고 할 수 있겠다.

또한, 나의 짧은 지식을 동원해 생각해보자면
정적 팩터리 메서드의 경우, 클래스의 인스턴스를 호출하지 않고도 생성 가능하다.
하지만, 팩터리 메서드 패턴의 경우에는 클래스의 인스턴스를 만들어야만 호출할 수 있다.
이것 또한 둘의 차이가 아닐까...?라고 생각하는데 틀렸다거나 자신의 생각과는 다르면 마구마구 지적해주시면 좋을 것 같다. 

 

기존 생성자 방식이 있음에도 정적 팩터리 메서드가 등장한 데는 이유가 있다. 또한, 모든 방식에 장점만 존재할 수는 없는 것❕ 정적 팩터리 메서드의 장점과 단점에 대해 알아보자.

---

장점

1. 이름을 가질 수 있다.

생성자에 넘기는 매개변수와 생성자만으로 반환되는 객체의 특성에 대해 파악하기 어렵다. 만약, 네이밍을 잘 한 정적 팩터리 메서드를 사용한다면 반환된 객체의 특성을 쉽게 묘사할 수 있다. 

BigInteger bigInteger = new BigInteger(3, new Random());​

이렇게 생성자를 활용하는 것보다

 

BigInteger.probablePrime => 값이 소수인 BigInteger 반환

해당 코드가 훨씬 어떤 객체를 반환하는지 파악하기 쉽다.

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

중요! 생성하지✌️는✌️에 유의하자. 처음 읽었을 때, '새로 생성하지 않는다.'라고 읽어서 이해가 잘 되지 않았다. 어미에 유의하자.

 

이러한 특성 덕분에 

불변 클래스 : 인스턴스를 미리 만들거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식 ➡️ 불필요한 객체 생성을 피할 수 있다.

 

같은 객체가 자주 요청되는 상황이라면 정적 팩터리 메서드는 성능을 크게 올려줄 수 있다.

'반복되는 요청 ➡️ 같은 객체 반환'하는 식으로 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제 가능하다. ➡️ 인스턴스 통제 클래스

 

• 인스턴스 통제하는 이유는?
  1. 클래스를 싱글턴으로 만들 수 있다.
  2. 클래스를 인스턴스화 불가로 만들 수 있다.
  3. 불변 값 클래스에서 동치인 인스턴스가 단! 하나뿐임을 보장할 수 있다.
  4. (다른 소리긴 함) 플라이웨이트 패턴의 근간이 된다. (플라이웨이트 패턴에 대해서는 추후... 글을 작성하겠다.)

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

반환할 객체의 클래스를 자유롭게 선택할 수 있는 "유연성"을 제공한다. API를 만들 때 구현 클래스를 공개하지 않고 그 객체를 반환할 수 있어 API를 작게 유지할 수 있다. API를 작게 유지하면 프로그래머가 API를 사용하기 위해 익혀야 하는 개념의 수와 난이도를 낮출 수 있다.

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

반환 타입의 하위 타입이기만 한다면 어떤 클래스의 객체를 반환하든 상관없다. 

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

이러한 점은 JDBC 등 서비스 제공자 프레임워크를 만드는 근간이 된다. 서비스 제공자 프레임워크에서의 제공자는 서비스의 구현체다. 그리고 이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해준다. 

---

단점

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

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

생성자처럼 API 설명에 명확히 드러나지 않으니 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 한다. 이를 위해 API 문서를 잘 써놓고 메서드 이름도 널리 알려진 규약을 따라 짓는 식으로 문제를 완화해줘야 한다.

 

 

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

• from : 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드
• of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드
• valueOf : from과 of의 더 자세한 버전
• instance 혹은 getInstance : (매개변수를 받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지✌️는✌️ 않는다.
• create 혹은 newInstance : instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다.
• getType : getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. "Type"은 팩터리 메서드가 반환할 객체의 타입이다.
• newType : newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. "Type"은 팩터리 메서드가 반환할 객체의 타입이다.
• type : getType과 newType의 간결한 버전

 

정적 팩터리 메서드와 public 생성자 모두 각자의 쓰임새와 장단점이 있으니 잘 이해하고 사용하는 것이 좋다. 저자의 말로는 정적 팩터리 메서드가 더 유리한 경우가 많으니 무작정 public을 사용하는 것은 지양하라고 한다. 

참고

1. 이펙티브 자바 3/E
2. https://refactoring.guru/design-patterns/factory-method
3. https://refactoring.guru/design-patterns/factory-comparison
4. https://velog.io/@jamieshin/%ED%8C%A9%ED%86%A0%EB%A6%AC-%EB%A9%94%EC%86%8C%EB%93%9C-%ED%8C%A8%ED%84%B4Factory-Method-Pattern