[이펙티브 자바] 아이템 1. 생성자 대신 정적 팩토리 메소드를 고려하라.
이펙티브 자바를 공부한 내용입니다.
생성자 대신 static factory method를 고려하라
우리가 인스턴스를 만들때 보통 생성자를 사용한다.
하지만 생성자 말고도 static factory method를 사용해서 인스턴스를 생성할 수 있다.
생성자를 통해 인스턴스를 만드는 것에 대한 단점과,
정적 팩토리 메서드를 사용할 때의 장단점을 알아보자.
public class Foo {
private String name;
private String job;
public Foo(String name) {
this.name = name;
}
public Foo(String job) {
this.job = job;
}
}
먼저 생성자로써 인스턴스를 만드는 경우이다.
위 코드는 문제점이 있다.
생성자도 메서드와 마찬가지로 오버로딩이 되는데
매개변수의 타입과 개수가 같다면 오버로딩을 할 수 없게 된다.
또한 Foo 객체를 만드는데 생성자에 어떠한 값을 필요로 하는지 클라이언트 입장에서는 알기 어렵다.
이와 같은 이유들로 인해 정적 팩토리 메서드를 사용하는 것을 고려해 볼 필요가 있다.
아래는 정적 팩토리 메서드의 장점과 단점이다.
정적 팩토리 메서드의 장점
**1. 이름을 가질 수 있다.**
앞서 말했듯이 생성자를 사용할 경우 클라이언트 입장에서는 매개변수에 어떤 값이 필요한지 알기 어렵다.
이때 정적 팩토리 메서드로 이름만 잘 지어주면 반환 될 객체가 무엇인지 쉽게 알 수 있다.
public class Foo {
private Foo() {}
private String name;
private String job;
public static Foo createFooName(String name) {
Foo foo = new Foo();
foo.setName(name);
return foo;
}
public static Foo createFooJob(String job) {
Foo foo = new Foo();
foo.setJob(job);
return foo;
}
public void setName(String name) {
this.name = name;
}
public void setJob(String job) {
this.job = job;
}
}
public class Client {
public static void main(String[] args) {
Foo fooName = Foo.createFooName("LEE");
Foo fooJob = Foo.createFooJob("Developer");
}
}
**2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.**
책에서는 Boolean.valueOf(boolean) 메서드를 대표적인 예로 들고 있다.
이미 상수로써 정의되어있는 객체를 반환하는 것을 알 수 있다.
생성하는데 비용이 크고 생성되는 빈도가 잦은 객체라면
정적 팩토리 메서드로 변경해, 호출 시 마다 객체를 만들지 않고 성능을 높일 수 있다.
자주 변하지 않는 객체를 캐싱해 재사용하는 Flyweight Pattern이 비슷한 기법이라고 볼 수 있다.
이러한 클래스는 인스턴스 통제 클래스 (noninstantiable)라 한다.
인스턴스 통제를 하면, 싱글톤을 적용할 수 있고, 인스턴스를 직접 만들지 못하게 만들 수 있다.
또한 JPA의 persist 상태의 객체와 같이, 객체가 하나임을 보장할 수 있다. (a == b 가 true)
**3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.**
하위 타입 객체를 반환할 수 있다는 것은 다시말해 유연성이 좋다는 의미이다.
이러한 유연성을 활용한다면, API 설계에서 구현 클래스를 공개하지 않고도 객체를 반환할 수 있다.
public class Foo {
public static Foo getFoo() {
return new Foo();
}
public static Foo getBar() {
return new Bar();
}
}
public class Bar extends Foo { }
위와 같이 얼마든지 상황에 맞게 하위 타입의 객체를 반환할 수 있다.
구현체가 아닌 인터페이스를 사용하는 것은 일반적으로 좋은 습관인데,
이러한 설계를 사용하면 클라이언트가 리턴받은 객체가 구현 클래스가 아닌 인터페이스를 사용할 수 있다.
책의 예시로는 java.util.Collections 클래스가 있다.
이 클래스는 45개의 인터페이스의 구현체를 제공하지만
이 구현체는 공개하지 않은 non-public이다.
interface내에 static 필드와, static 멤버 클래스는 여전히 public만을 지원하지만
자바8 부터는 인터페이스 내에 static 메서드를 사용할 수 있고,
자바9 부터는 private static 메서드도 지원하기 때문에,
필드와 멤버 클래스를 제외한 코드라면 Collections와 같은 클래스는 이제 만들지 않아도 된다.
**4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.**
3번과 비슷한 맥락으로 볼 수 있다.
매개변수에 따라 반환 타입이 하위 타입이라면, 어떠한 타입을 반환해도 상관 없다.
public class Foo {
public static Foo getFoo(String type) {
if (type.equals("Foo")) {
return new Foo();
} else (type.equals("Bar")) {
return new Bar();
} else {
throw new UnsupportedOperationException();
}
}
}
public class Bar extends Foo { }
책의 예시로는 EnumSet 클래스가 있다.
EnumSet 클래스는 public 생성자 없이 정적 팩토리만 제공한다.
noneOf 메서드는 Enum의 원소가 64개 이하라면 RegularEnumSet을
65개 이상이라면 JumboEnumSet을 반환한다.
클라이언트는 이렇게 리턴된 타입의 정체를 알 수 없다.
앞서 말했듯이 구현체가 아닌 인터페이스를 (혹은 추상클래스) 사용하는 것은 좋은 습관이다.
만약 나중에 RegularEnumSet이 필요 없어져 제거가 되어도,
Enum의 원소 개수를 더욱 세분화하여 SuperBiggestJumboEnumSet이 생기더라도
서버와 클라이언트 모두 전혀 부담이 없다.
**5. 정적 팩토리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.**
public class Foo {
public static Foo newInstance(String filePath) {
try {
Class<?> aClass = Class.forName(filePath);
return (Foo) aClass.getDeclaredConstructor().newInstance();
} catch (ClassNotFoundException | InstantiationException | IllegalAccessException | InvocationTargetException | NoSuchMethodException e) {
throw new RuntimeException();
}
}
}
public class Bar extends Foo { }
public class App {
public static void main(String[] args) {
String filePath = "gicheol.effectivejava.item.item1.Bar";
Foo foo = Foo.newInstance(filePath);
System.out.println("foo = " + foo);
}
}
// foo = gicheol.effectivejava.item.item1.Bar@26ba2a48
정적 팩토리 메서드의 단점
**1. 정적 팩토리 메서드만을 제공하면 하위 클래스를 만들 수 없다.**
상속을 하려면 public이나 protected 생성자가 필요하다.
그러나 정적 팩토리 메서드만 제공한다면 생성자는 default 혹은 private일 것 이다.
그러나 사실 상속보다 (is-a 관계) 컴포지션을 (has-a 관계) 사용하도록 유도하고,
변경 가능성을 최소화로 하는 불변 타입으로 만들기 위해서는 이 제약을 지켜야 한다는 점에서 오히려 장점일수도 있다.
**2. 정적 팩토리 메서드는 프로그래머가 찾기 어렵다.**
생성자와는 다르게 정적 팩토리 메서드는 javadoc API 설명에 명확하게 드러나지 않는다.
많은 메서드들 사이에서 어떤 것이 정적 팩토리 메서드인지 찾기 쉽지 않다.
아래는 Collections 클래스의 javadoc 이다.
그렇기 때문에 일반적으로 사용하는 네이밍 컨벤션에 맞춰 메서드를 만드는 것이 좋다.
혹은 SpringApplication 클래스와 같이 사용 방법에 대한 주석을 달도록 하자.
Leave a comment