Item1. 생성자 대신 정적 팩터리 메서드 고려하라
1
팩토리 메서드 패턴으로 기능에 따라 이름을 가질 수 있음.
package com.org.lhd.effectivejava3.item01;
public class Member {
private String name;
private int height;
private int age;
public Member(String name, int height) {
this.name = name;
this.height = height;
}
public Member(String name, int age) {
this.name = name;
this.age = age;
}
}
위의 예시처럼 자바에서는 같은 파라미터 타입을 가지는 생성자를 만들게 되면 오류가 발생함.
2
자바의 생성자는 매번 새로운 인스턴스를 만들어 진다. (hashcode로 조회해볼 수 있음) 생성자를 통하여 인스턴스를 만들어주면 통제가 불가능함. 유일한 인스턴스만 만들어야 한다면 정적 팩터리 인스턴스를 만들어서 사용해야함. (객체 생성을 막아버려 존재하는 인스턴스를 가져오게 할 수 있음.) - flyweight pattern
3
정리
- 이름을 가질 수 있음
- 매번 객체를 생성하여 사용하지 않음.
- 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있음.
- 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있음.
- 하위 클래스이기만 하면 되고 클라이언트 입장에서 두 클래스 존재를 모른다.
- 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 됨.
- 서비스 프레임워크를 만드는 근간
- 열거 타입은 인스턴스가 하나만 만들어짐을 보장
- 같은 객체가 자주 요청되는 상황이라면 플라이웨이트 패턴을 사용할 수 있음
- 인터페이스가 정적 메서드를 가질 수 없다는 제한이 풀렸기 때문에 인스턴스화 불가 동반 클래스를 둘 이유가 별로 없음
- 서비스 제공자 프레임워크를 만드는 근간 -> 정적 팩터리 메서드
- 서비스 제공자 인터페이스가 없다면 각 구현체를 인스턴스로 만들 때 리플렉션을 사용
- 브리지 패턴
- 의존 객체 주입 프레임워크