[이펙티브 자바] 아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

정적 메소드(Static Method)와 정적 필드(Static Field)만을 담은 클래스의 예

1) 기본 타입 값이나 배열 관련 메서드들을 모아놓은 클래스 

- java.lang.Math 클래스는 2개의 변수와 70여개의 메서드를 가지고 있는데, 전부 static이다.

덧셈, 곱셈, 최대값 구하기 등 기본적인 수학 연산 결과를 리턴하는 만큼, 객체마다 다른 상태값과 로직을 가지게 할 필요가 없기 때문에 모든 변수와 메서드를 static으로 구현한 것 아닐까 싶다.

Math 클래스의 API 문서

 

2) 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩토리)를 모아놓은 클래스

- java.util.Collections는 문서 초반에 대놓고 컬렉션을 리턴하거나 컬렉션을 다루는 static method만을 포함하고 있다고 이야기한다. 

아예 첫줄에 "This class consists exclusively of static methods"라고 한다

 

그런데, 책에서 이야기하는 "특정 인터페이스를 구현하는 객체를 생성해준다" 가 구체적으로 무슨 의미인가 싶다.

API 문서를 확인해보면 Collections 클래스의 메서드들은 boolean, int와 같은 기본값을 리턴하는 경우를 제외하고는 대부분 Collection, List와 같은 인터페이스 타입으로 값을 받고, 또 결과값을 리턴한다.

 

이중에서 checkedList라는 아래 메서드를 보면 List<E>와 Class<E> 타입의 매개변수를 받아 List<E>를 리턴한다.

딱히 List 인터페이스를 구현한 객체를 생성해주는 것 같다는 생각이 안 들었는데,  내용을 자세히 보니상황에 따라 CheckedRandomAccessList 혹은 CheckedList 객체를 리턴해준다. 찾아보면 두 개 클래스 모두 Collections 내부에서 List를 상속받아 구현되어 있다.

아마 이런 식으로 메서드 시그니쳐에는 List, Collection 등의 인터페이스 타입을 리턴한다고 되어 있어도 실제로는 특정 인터페이스를 구현한 객체를 리턴해준다는 의미이지 않을까 싶다.  

 

3) Final 클래스와 관련한 메서드들을 모아놓은 클래스 

- 일단, final 키워드가 붙어 있는 클래스를 상속받아서 새로운 클래스를 만드는 것은 불가능하다.

Formatter라는 클래스가 있다. 한 번도 써본적은 없는데, 여튼 이 클래스에는 final 키워드가 붙어있다. Formatter의 toString() 메서드를  쓸때마다 동일한 메세지를 출력하도록 하고 싶어서  Formatter를 상속받는 클래스인 ExtendFinalClass를 만드려고 했다고 하자.

하지만 IDE가 친절하게도 불가능하다고 에러 메세지를 뱉어준다. Final이라는 키워드 자체에 '변경될 수 없는'이라는 의미 이외에도  '확장될 수 없는' 라는 의미도 포함되어 있는 것 아닐까 싶다. 

여튼, 이럴 때 사용할 수 있는 하나의 방법은 아래와 같이 Fomatter를 매개변수로 전달받는 static 메서드를 만들어 보는 것이다.

ExtendFinalClass에는 1개의 static method만 있다

ExtendFinalClass를 이용해서 Formatter의 구현체들이 동일한 행위를 하도록 한다

일다 Formatter가 뭐하는지도 잘 모르는 클래스인데, final class라는 이유 하나만으로 사용했기 때문에 부적절한 예시이기는 하지만 조슈아씨가 대략 이런 느낌으로 말한 것 같다. 

 

인스턴스화를 막으려면 Private 생성자를 추가하라

위와 같이 '정적 멤버만 담은 유틸리티 클래스'는 대개 인스턴스를 만드려고 설계한 클래스들이 아니다. 즉, 사용자가 ExtendFinalClass extendFinalClass = new ExtendFinalClass()를 하게 만들어서는 안 된다. 하지만 내가 만든 ExtendFinalClass는 아래 14번째 줄처럼 인스턴스화가 가능하다. 

당연하다. 내가 따로 생성자를 명시하지 않았기 때문에, 컴파일러가 아래와 같이 public한 기본 생성자를 만들어주었다.

파일명을 보면 .java가 아니라 .class, 즉 컴파일된 파일이다

이렇게 되면 ExtendFinalClass의 의도를 잘 모르는 사용자는 마음대로 인스턴스를 생성해버릴 수도 있다. 이러한 상황을 막기 위해 아래와 같이 접근 제어자가 private인 기본 생성자를 만들어둔다.

이렇게 되면 컴파일 시에 public한 기본 생성자가 생겨나지도 않으며, 사용자가 인스턴스를 만드는 것도 불가능하게 된다. 

9번째 줄의 AssertionError()는 ExtendFinalClass 내부에서도 인스턴스를 만드는 것을 막기 위해 넣어놓은 로직이다. 저렇게 에러(Exception이 아닌 Error이다)를 던지도록 해놓고 18번째 라인에서 ExtendFinalClass 내부에서 생성자를 호출할 수 있게 해보았다.

ExtendFinalClass를 사용하는 Item04 프로그램을 실행해보면 아래와 같이 에러를 뱉으며 프로그램을 멈춰버린다. 

 

AssertionError에 대한 여담

 

장의 주제와는 벗어나지만, 생성자 안에 Error가 아닌 RuntimeException을 던지도록 하면 아래와 같이 메세지가 출력된다.

9번째 줄에서 Error가 아닌 Exception을 던지도록 했다.

AssertionError를 사용했을 때에는 그래도 "do something"은 출력했는데, RuntimeException은 아무것도 던지지 않는다. 왤까?

 

결론

- 정적 필드와 정적 메서드만을 포함하는 클래스들은 대개 유틸리티 성격을 가지고 있으며, 유틸리티 성 클래스들은 대개 인스턴스화가 되어서는 안 된다. 

- 인스턴스화를 막으려면 private 생성자가 붙은 기본 생성자를 꼭 만들어두어라. 그렇지 않으면 컴파일러가 알아서 public한 기본 생성자를 만들 것이다.

- 조금 더 엄격하게 인스턴스화를 막고 싶다면, private 기본생성자 내부에서 에러를 뱉도록 해라.