1. 개념
단순히 정적 메서드와 정적 필드만을 담은 클래스를 생성하는 경우가 있다. 객체 지향적 사고하지 않는 이들이 종종 남용하지만 쓰임새는 분명히 존재한다.
단순히 정적 메서드와 정적 필드만으로 클래스를 생성하는 경우
- 기본 타입 값이나 배열 관련 메서드의 집합 ex) java.lang.Math, java.Util.Arrays
- 특정 인터페이스를 구현하는 객체를 생성해 주는 정적 메서드의 집합 ex) java.util.Collections
- final 클래스와 관련된 메서드의 집합 (final 클래스를 상속해서 하위 클래스에 메서드를 넣는 것은 불가능하기 때문)
해당 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰기 위해 설계한 것이 아니지만 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어주기에 매개변수를 받지 않는 public 생성자가 만들어지며, 사용자는 이 생성자가 자동생성된 것인지 구분할 수 없다.
실제로 공개된 API들에서도 이처럼 의도치 않게 인스턴스화할 수 있게 된 클래스가 종종 보인다. 단순히 추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다. 하위 클래스를 만들어 인스턴스화하면 그만이기 때문이다. 이 경우 사용자는 상속해서 사용하라는 것으로 오해할 수도 있으니 문제이지만, 다행히 인스턴스화를 막는 것은 간단하다.
컴파일러가 기본생성자를 만드는 경우는 오직 명시된 생성자가 없을 때뿐이니 private 생성자를 추가하면 클래스의 인스턴스화를 막으면 된다. 책의 예제를 확인해보자.
public class UtilityClass {
// 기본 생성자가 만들어지는 것을 막는다(인스턴스화 방지용).
private UtilityClass() {
throw new AssertionError();
}
}
명시적 생성자가 private이니 클래스 밖에서는 접근불가하다. AssertionError()도 필요 없지만 혹시 클래스 내에서 호출된 경우를 방지한다. 이 코드는 어떤 상황에서도 클래스가 인스턴스화되는 것을 방지한다.
(하지만 생성자가 존재하는데 호출이 불가한 상태이니 코드만 봐선 직관적이지 않다. 앞의 코드처럼 적절한 주석을 달아주자)
이방식은 상속을 불가능하게 하는 효과도 있다. 모든 생성자는 명시적이든 묵시적이든 상위 클래스의 생성자를 호출하게 된다. 이를 private으로 선언해 두면 하위 클래스가 상위 클래스의 생성자에 접근할 길이 없게 된다.
2. 결론
객체 지향적 사고와 어울리지 않지만 정적 메서드/정적필드만을 담을 클래스를 생성해야 할 경우가 있다. 이 경우에는 private 생성자를 통해 인스턴스화를 막아주어 클래스 내/외부에서의 생성자 호출을 막아주자.
책의 예제 소스와 상세 내용은 다음 repo에서 확인 가능
https://github.com/junhkang/effective-java-summary/tree/master/src/main/java/org/example/ch01/item04
'이펙티브 자바' 카테고리의 다른 글
[이펙티브 자바] 6. 불필요한 객체 생성을 피하라 (0) | 2024.03.26 |
---|---|
[이펙티브 자바] 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 (0) | 2024.03.25 |
[이펙티브 자바] 3. private 생성자나 열거 타입으로 싱글턴임을 보장하라 (2) | 2024.01.24 |
[이펙티브 자바] 2. 생성자에 매개변수가 많다면 빌더를 고려하라 (1) | 2024.01.23 |
[이펙티브 자바] 1. 생성자 대신 정적 팩터리 메서드를 고려하라 (0) | 2024.01.18 |