개발을 하다 보면 단순히 정적 메서드와 정적 필드만을 담은 클래스(유틸리티 클래스)를 만들고 싶을 때가 있을 것이다.
객체 지향적으로 사고하지 않는 이들이 종종 남용하는 방식이기에 그리 곱게 보이지는 않지만 분명 나름의 쓰임새가 있다.
예컨대 java.lang.Math와 java.util.Collections처럼 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓을 수도 있다.
마지막으로 final 클래스와 관련한 메서드들을 모아놓을 때도 사용한다.
final 클래스를 상속해서 하위 클래스에 메서드를 넣는 건 불가능하기 때문이다.
만약 정적 멤버만 담은 유틸리티 클래스를 만들 때, 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어준다.
하지만 우리는 유틸리티 클래스를 인스턴스로 만들어 쓰려고 설계한 것이 아니다.
인스턴스화를 방지하기 위해 추상 클래스로 선언하는 것을 생각할 수도 있다.
그러나 추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다.
하위 클래스를 만들어 인스턴스화하면 그만이다.
public abstract class AbstractUtilClass {}
class UtilClass extends AbstractUtilClass{}
위와 같이 말이다.
다행히도 인스턴스화를 막는 방법은 너무나 간단하다.
컴파일러가 기본 생성자를 만들어주는 경우는 오직 명시된 생성자가 없을 때 뿐이므로 private 생성자를 추가하여 클래스의 인스턴스화를 막을 수 있다.
다음은 그 예시이다.
public class UtilClass {
private UtilClass(){
throw new AssertionError();
}
}
추가로 하위 타입을 생성하는 것도 방어할 수 있다.
명시적 생성자가 private이므로 클래스 바깥에서는 접근할 수 없다.
꼭 AssertionError()를 발생시킬 필요는 없지만 클래스 안에서 실수로라도 생성자를 호출하지 않도록 해준다.
'☕️ Java > 이펙티브 자바' 카테고리의 다른 글
[Effective Java] 아이템 6 - 불필요한 객체 생성을 피하라 (0) | 2022.02.03 |
---|---|
[Effective Java] 아이템 5 - 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 (0) | 2022.02.02 |
[Effective Java] 아이템 3 - private 생성자나 열거 타입으로 싱글턴임을 보증하라 (0) | 2022.02.02 |
[Effective Java] 아이템 2 - 생성자에 매개변수가 많다면 빌더를 고려하라 (0) | 2022.01.23 |
[Effective Java] 아이템 1 - 생성자 대신 정적 팩터리 메서드를 고려하라 (0) | 2022.01.22 |