가끔 단순히 정적 메서드와 정적 필드만을 담은 클래스를 만들고 싶을 때가 있다.
객체 지향적으로 사고하지 않는 이들이 종종 남용하는 방식이지만, 나름의 쓰임새가 있다.
예를 들어, java.lang.Math와 java.util.Arrays 처럼 기본 타입 값이나 배열 관련 메서드들을 모아 놓을 수 있다.
java.util.Collection 처럼 특정 인터페이스를 구현하는 갳레를 생성해주는 정적 메서드를 모아 놓을 수도 있다.
마지막으로, final 클래스와 관련한 메서드들을 모아놓을 때도 사용한다.
final 클래스를 상속해서 하위 클래스에 메서드를 넣는 건 불가능하기 때문이다.
정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 게 아니다.
하지만 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어 준다.
즉 매개변수를 받지 않는 public 생성자가 만들어 지며, 사용자는 이 생성자가 자동 생성된 것인지 구분할 수 없다.
실제로 공개된 API들에서도 이처럼 의도치 않게 인스턴스화할 수 있게 된 클래스가 종종 목격되곤 한다.
추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다.
하위 클래스를 만들어 인스턴스화하면 그만이다. 이를 본 사용자는 상속해서 쓰라는 뜻으로 오해할 수 있어서 더 큰문제가 될 수있다.
이러한 인스턴스화를 막는 방법은 아주 간단하다.
컴파일러가 기본 생성자를 만드는 경우는 오직 명시된 생성자가 없을 때 뿐이다.
따라서, 이럴 때는 private 생성자를 추가해서 클래스의 인스턴스화를 막도록 하자.
public class UtilityClass{
//기본 생성자가 만들어지는 것을 막는다.(인스턴스화 방지용)
private UtilityClass(){
throw new AssertionError();
}
...//코드생략
}
이렇게 구현하게되면 명시적 생성자가 private이기 때문에 클래스 바깥에서는 접근할 수 없다.
꼭 AssertionError를 던질 필요는 없지만, 클래스 안에서 실수로라도 생성자를 호출하지 않도록 해준다.
이 코드는 어떤 환경에서도 클래스가 인스턴스화 되는 것을 막아준다.
근데, 생성자가 분명 존재하는데 호출할 수가 없으니 그다니 직관적으로 볼 수는 없다.
따라서 헷갈리지 않도록 앞에 적절한 주석을 달도록 하자( ex. 인스턴스화 방지용)
결론적으로 이 방식은 상속을 불가능하게 하는 효과도 있다.
모든 생성자는 명시적이던 묵시적이던 상위 클래스의 생성자를 호출하게 되는데, 이를 private으로 호출했기 때문에 하위 클래스가 상위 클래스의 생성자에 접근할 길이 막혀버린다.
참고 : 책, 이펙티브 자바 3/E
'Backend > Java' 카테고리의 다른 글
[이펙티브자바] 불필요한 객체 생성을 피하자. (0) | 2021.07.06 |
---|---|
[이펙티브 자바] 의존 객체 주입을 사용하자. (0) | 2021.06.10 |
[이펙티브 자바] 싱글턴 객체를 보장하는 세가지 방법 (0) | 2021.06.04 |
[이펙티브 자바] 생성자에 매개변수가 많을 때 효율적인 해결 방법 (0) | 2021.06.02 |
[이펙티브 자바] 생성자 대신 정적 팩토리 메서드를 고려하라. (2) | 2021.06.01 |