정적 팩토리 메소드(Static Factory Method) 장단점

이펙티브 자바 책 공부중 내용 정리가 필요 할것 같아 정리합니다.

참고 하실 분들은 아래 색 보시고 참고 하시면 될것 같습니다.

검정 : 책내용

파랑 : 정리 

빨강 : 중요

장점

---

1) 이름을 가질 수 있다.

- 생성자의 매개변수와 생성자 그 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다.

반면, 정적 메소드는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사 가능하다. 예를 들면

BigInterger(int, int, Random); // 기본 생성자.

BigInterger.probablePrime(); // 정적 팩토리 메소드.

위의 경우 둘 중 정적 팩토리 메소드가 probablePrime이 '값이 소수인 BigInterger를 반환한다.' 라는 의미가 명확하다.

- 생성자는 하나의 시그니처(같은 매개변수 타입을 가진 생성자)로는 생성자 하나만 만들 수 있다. 

하지만, 이름을 가질 수 있는 메소드는 이런 제약이 없다.

=> 단순하게 매개변수를 활용한 오버로딩만 가능한 생성자와는 다르게 정적 팩토리 메소드의 경우 이름을 통한 구분이 가능한 메소드는 좀더 사용자에게 직관적으로 다가가고 활용도가 높아진다.

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

- 불변 클래스를 만들 경우 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하는 식으로 불필요한 객체 생성을 피할 수 있다.

따라서 비용이 큰 객체가 자주요청 되는 상황이라면 성능을 상당히 끌어 올릴 수 있다. 

- 반복되는 요청에 같은 객체를 반환하는 식으로 정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지를 통제할 수 있다.

이런 클래스를 인스턴스 통제 클래스라 한다.

- 이런 방식으로 클래스를 만들면 싱글톤이라던가, 인스턴스화 불가 같은 형태의 클래스를 만들 수도 있다. 

- 인스턴스 통제는 플라이웨이트 패턴의 근간이 되기도 한다.

=> 해당 클래스로 만들어질 객체의 수량을 조절 가능하다는게 주 내용. 이러한 방식으로 객체의 갯수를 1개로 제한하면 싱글톤, 객체를 생성하지 못하고 정적으로만 사용 가능하면 인스턴스화 불가 객체가 없다면 만들고 그 이미 있다면 그 객체를 공유하는 플라이 웨이트 패턴 등이 그 사용예이다.

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

- 이는 반환할 객체의 클래스(리턴 타입의 상속을 받은 모든 클래스 가능)를 자유롭게 선택할 수 있게 하는 유연성을 제공한다.

 

- API 생성시 이 유연성을 이용하면 구현 클래스를 공개하지 않아도 되기 때문에 API를 작게 유지할 수 있다.

자바 8 이전에는 인터페이스에서 정적 메소드를 선언할 수 가 없었기 때문에(구현되있는 메소드가 존재한다면 인터페이스의 추상성을  해칠수도 있기 때문) 해당 인터페이스를 반환하는 클래스 구현하기 위해서는 인스턴스화 불가의 동반 클래스를 만들어 사용했다.

=> 인터페이스로 정적 팩토리 메소드를 구현하면 다형성을 가진 객체를 제공해줄 수 있다.

=> pulbic 외의 정적(static) 메소드는 Java8버전까지는 제공하지 않는다.

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

- 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다. 클라이언트는 이 두 클래스의 존재를 모른다.

=> 예를 들어 A라는 클래스를 B라는 클래스가 상속(B extends A)의 상황일 때 A 클래스에서 리턴 타입이 A인 정적 팩토리 메소드가 있다면 이 메소드는 A나 B 둘중 어떤 객체를 반환해도 상관없다.

=> B는 A가 가지고 있어야할 모든 멤버를 갖추고 있고, 그 성질만 다르기 때문.

- 이를 활용하면 기존 버전에서 다음 릴리즈로 넘어갈 때 기존의 타입이 유용하지 못하다면 삭제 후 다른 타입을 반환 해줄 수 있다. 

=> A를 상속받은 클래스라면 그것이 B이든 C이든 넘겨줄 수 있고, 이는 이 객체를 사용하는 사용자에겐 아무런 영향을 미치지 않는다. 그러므로 버전을 올릴때 리턴하는 객체를 변경해줄 수 있다.

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

- 이러한 유연함은 서비스 제공자 프레임워크(Service provider framework)를 만드는 근간이 된다.

 예를들어, JDBC(Java Database Connectivity)의 경우 서비스 제공자 프레임워크에서의 제공자는 서비스 구현체이다.

이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해 준다.

 서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 이루어짐, 서비스 인터페이스, 제공자 등록 API, 서비스 접근 API가 이 3가지이다.

그 외, 3개의 핵심 컴포넌트와 더불어 종종 서비스 제공자 인터페이스라는 네번째 컴포넌트가 쓰이기도 한다.

JDBC 에서는 Connection이 인터페이스 역할을, DriverManager.registerDriver가 제공자 등록 API, DriverManager.getConnection이 서비스 접근 API역할을 Driver가 서비스 제공자 인터페이스 역할을 수행한다.

=> 인터페이스나 클래스가 만들어 지는 시점에서 하위 타입의 클래스가 존재 하지 않아도 나중에 만들 클래스가 기존의 인터페이스나 클래스를 상속 받는 상황이라면 언제든지 의존성을 주입 받아서 사용이 가능하다.

=> 이를 활용하여서 JDBC라는 서비스의 규칙을 지킨(Connection 인터페이스를 구현한 DB회사의 라이브러리 등) 여러 DB를 사용 가능 하게된다.

단점

---

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

- 앞서 이야기한 구현 클래스들을 상속할 수 없다는 이야기다.

- 이 제약은 상속보다 컴포지션을 사용하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 오히려 장점으로 받아들일 수도 있다.

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

- 생성자처럼 API 설명에 명확히 드러나지 않으니 사용자는 정적 팩토리 메소드 방식 클래스를 인스턴스화할 방법을 알아내야 한다. 이 일을 언젠가 자바독이 알아서 처리해 줬으면 좋겠으나, 그날이 오기 까지는 API 문서를 잘 써놓고 메서드 이름도 널리 알려진 규약을 따라 짓는 식으로 문제를 완화 해줘야한다.

* 정적 팩토리에서 흔히 사용하는 명명 방식.

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

* 핵심 정리

정적 팩토리 메소드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다. 그렇다고 하더라도 정적 팩토리를 사용하는 게 유리한 경우가 더 많으므로 무작정 pulbic 생성자를 제공하던 습관이 있다면 고치자.