Effective Java | #1. 생성자 대신 정적 팩터리 메서드를 고려하라

보람·2022년 5월 6일

Effective-Java

목록 보기

2/25

생성자 외에 인스턴스를 얻는 방법

클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자
클래스는 생성자와 별도로 정적 팩터리 메서드(static factory method) 제공 가능
- 정적 팩터리 메서드 : 해당 클래스의 인스턴스를 바로 반환하는 단순 정적 메서드(디자인 패턴의 팩터리 메서드와는 다름)

/**
 * 기본 타입인 boolean 값을 받아 Boolean 객체 참조로 변환해주는 정적 팩터리 메서드
 */
public static Boolean valueOf(boolean b) {
	return b ? Boolean.TRUE : Boolean.FALSE;
}

클래스는 public 생성자 대신 정적 팩터리 메서드를 제공할 수 있는데 이에는 장단점이 따른다.

정적 팩터리 메서드가 생성자보다 좋은점(장점)

책에서는 다섯 가지를 언급했다.

첫 번째, 이름을 가질 수 있다.

생성자는요..
- 이름X -> 반환될 객체의 특성이 제대로 설명 안됨
- BigInteger(int, int, Random) --> 무슨일을 하는 객체의 생성자인지 가늠 어려움
- 입력 매개변수들 별로 다른 생성자를 새로 추가하는 것은 좋지 않음 -> 문서화의 어려움, 기억하기 어려움(호출실수 등등)
반면, 정적 팩터리는요..
- 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사 가능
- BigInteger.probablePrime : 값이 소수인 BigInteger를 반환하는 정적 팩터리 메서드
  - 얘가 뭐하는 놈이다!! 라는걸 쉽게 알 수 있는 느낌?
- 클래스 내부에 시그니처가 같은 생성자가 여러개 필요하다면 차이가 잘 드러나는 이름의 정적 팩터리 메서드로 바꾸자!

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

이 특성으로 불변 클래스(item-17)는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식 -> 불필요한 객체 생성 방지
같은 객체가 자주 요청되는 경우라면 더욱 효과적 ex) Boolean.valueOf(boolean) | 플라이웨이트 패턴
어떤 인스턴스를 언제 살아 있게 할지 정하는 instance-controlled 클래스처럼 반복 요청에 같은 객체를 반환하는 식이 가능

인스턴스 통제 이유는?

통제하면 클래스를 싱글턴(item-3)으로 만들 수도, 인스턴스화 불가(noninstantiable)(item-4)로 만들기 가능
불변 클래스(item-17)에서 동치 인스턴스가 단 하나임을 보장 가능
플라이웨이트 패턴의 근간 & 열거 타입(item-34) 단일 생성 보장

세 번째, 반환 타입의 하위 타입 객체를 반환할 수 있는 능력

이 엄청난 유연성은 API를 만들때 구현 클래스 공개 없이도 객체 반환이 가능하여 작은 API 유지 가능
- 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크(item-20)를 만드는 핵심 기술
자바 컬렉션 프레임워크는 수정 불가&동기화 기능을 덧붙인 45개 유틸리티 구현체 중 대부분을 java.util.Collections라는 단 하나의 인스턴스화 불가 클래스에서 정적 팩터리 메서드를 통해 얻도록 했다.

45개 클래스 공개 X

작은 API, API를 사용하기 위한 난이도&개념 ↓
정적 팩터리 메서드를 사용하는 클라이언트는 얻은 객체를 (구현 클래스X) 인테페이스만으로 다루게 되며(item-64) 이는 좋은 습관임

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

EnumSet 클래스(item-36)는 public 생성자X, 정적 팩터리만 제공, 원소 수에 따라(매개변수에 따라) 두 가지 하위 클래스중 하나의 인스턴스를 반환
- 원소 64개 이하 : RegularEnumSet 인스턴스
- 원소 65개 이상 : JumboEnumSet 인스턴스
- 클라이언트는 위 두 클래스 존재를 모르고 필요에 따라 성능을 더 개선한 세번째, 네번째 클래스를 다음 릴리스에 추가 가능

보람혼자정리) 클라이언트가 호출시 입력한 매개변수에 따라서 두개의 클래스가 존재하는지도 어떤 클래스의 인스턴스인지도 몰랐지만 클라이언트가 원하는 객체를 얻을 수 있는 것인듯? 좋군

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

이런 유연함은 service provider framework를 만드는 근간이 되는데

service provider framework

대표적 예로는 JDBC
(괄호는 JDBC에서의 역할)서비스 제공자 프레임워크 구성
- (Connection)service interface : 구현체 동작 정의
- (DriverManager.registerDriver)service registration API : 구현체 등록시 사용하는 제공자 등록 API
- (DriverManager.getConnection)service access API : 서비스의 인스턴스를 얻을 때 사용하는 접근 API
  - 접근시 원하는 구현체 조건 명시 가능, 명시 안한 경우 기본 구현체 반환 or 지원하는 구현체들을 하나씩 돌아가며 반환 -> 유연한 정적 팩터리의 실체
- 종종 사용하는 (Driver)service provider interface : 서비스 인터페이스의 인스턴스를 생성하는 팩터리 객체를 설명
- 서비스 제공 프레임워크가 없다면 각 구현체를 인스턴스로 만들 때 리플렉션(item-65) 사용
서비스 제공자 프레임워크 패턴 여러 변형
- 브리지 패턴 : 서비스 접근 API는 공급자가 제공하는 것보다 더 풍부한 서비스 인터페이스를 클라이언트에서 반환 가능
- 의존 객체 주입(dependency injection) 프레임워크(item-5)
- ServiceLoader(item-59)

모든것이 완벽할 순 없쥬..🥺

정적 팩터리 메서드 단점

첫 번째, 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.

상속을 하려면 public or protected 생성자 필요
컬렉션 프레임워크의 유틸리티 구현 클래스들은 상속 X
- 상속 대신 컴포지션(item-18) 사용을 유도하고
- 불변 타입(item-17)으로 만들려면 이 제약을 지켜야 한다는
  - 점에서 오히려 장점이 될수도?0?