Effective Java 아이템 4: 인스턴스화를 막으려거든 private 생성자를 사용하라
메타 설명: 정적 메서드와 필드만을 담은 유틸리티 클래스는 인스턴스화될 필요가 없습니다. Effective Java 아이템 4를 통해 private 생성자를 사용하여 인스턴스화를 막고, 코드의 안정성과 명확성을 높이는 방법을 알아봅니다.
URL 슬러그: effective-java-item4-private-constructor
서론: 왜 인스턴스화를 막아야 할까?
Java 프로그래밍을 하다 보면, java.lang.Math나 java.util.Arrays처럼 정적(static) 메서드와 필드만을 모아놓은 유틸리티 클래스를 작성할 때가 많습니다. 이러한 클래스들은 객체를 생성하여 상태를 가지는 것이 아니라, 단순히 기능적인 메서드를 제공하는 것이 목적입니다. 따라서, 개발자의 의도와 다르게 이러한 클래스가 인스턴스화(객체 생성)되는 것을 막아야 할 필요가 있습니다.
만약 유틸리티 클래스의 인스턴스 생성을 막지 않는다면, 사용자들은 불필요한 객체를 생성하여 메모리를 낭비하거나, 해당 클래스가 상태를 가질 수 있다고 오해할 수 있습니다. 이는 코드의 예측 가능성을 떨어뜨리고, 잠재적인 버그의 원인이 될 수 있습니다. 그렇다면 어떻게 유틸리티 클래스의 인스턴스화를 효과적으로 막을 수 있을까요? Effective Java의 저자 조슈아 블로크는 아이템 4에서 private 생성자를 사용하라는 명쾌한 해답을 제시합니다. 이 글에서는 private 생성자를 사용하여 인스턴스화를 막는 방법과 그 이점에 대해 자세히 알아보겠습니다.
본론 1: 인스턴스화를 막는 private 생성자
클래스의 인스턴스화를 막는 가장 확실하고 간단한 방법은 private 생성자를 추가하는 것입니다.
public class StringUtils {
// private 생성자로 인스턴스화를 막는다.
private StringUtils() {
// AssertionError를 던져 클래스 내부에서도 생성자를 호출하는 것을 막는다.
throw new AssertionError("This class should not be instantiated.");
}
public static boolean isNullOrEmpty(String str) {
return str == null || str.isEmpty();
}
public static String reverse(String str) {
if (str == null) {
return null;
}
return new StringBuilder(str).reverse().toString();
}
}
위 StringUtils 클래스는 문자열 관련 유용한 정적 메서드들을 제공합니다. 이 클래스에 private 생성자를 추가함으로써, 외부에서 new StringUtils()를 통해 객체를 생성하려는 시도를 컴파일 시점에 차단할 수 있습니다. 컴파일러는 생성자가 private으로 선언되었기 때문에 접근할 수 없다는 오류를 발생시킵니다.
AssertionError를 던지는 이유
private 생성자 내부에서 AssertionError를 던지는 것은 추가적인 방어 장치입니다. 클래스 내부의 다른 메서드에서 실수로 생성자를 호출하는 경우를 방지하기 위함입니다. 만약 내부에서 생성자를 호출하더라도, AssertionError가 발생하여 인스턴스 생성이 불가능하다는 것을 명확하게 알려줍니다. 이는 코드를 작성한 프로그래머의 의도를 명확히 하고, 클래스가 설계된 목적대로 사용되도록 보장합니다.
본론 2: private 생성자의 이점
private 생성자를 사용하여 인스턴스화를 막는 방법은 여러 가지 이점을 제공합니다.
1. 명확한 의도 전달
private 생성자는 해당 클래스가 인스턴스화될 목적이 아님을 코드 수준에서 명확하게 보여줍니다. 다른 개발자들이 이 클래스를 사용할 때, 불필요한 객체를 생성하지 않고 정적 멤버에 바로 접근해야 한다는 것을 쉽게 이해할 수 있습니다. 이는 코드의 가독성과 유지보수성을 높이는 데 기여합니다.
2. 상속 방지 효과
클래스에 private 생성자만 존재하면, 다른 클래스가 이 클래스를 상속(extends)할 수 없습니다. 하위 클래스의 생성자는 반드시 상위 클래스의 생성자를 호출해야 하는데, 상위 클래스의 생성자가 private이므로 접근할 수 없기 때문입니다. 이는 유틸리티 클래스가 의도치 않게 확장되어 오용되는 것을 막아줍니다. 만약 상속을 허용하면서 인스턴스화만 막고 싶다면, protected 생성자를 사용하는 것을 고려할 수 있지만, 유틸리티 클래스의 경우 상속을 막는 것이 더 바람직한 설계일 때가 많습니다.
3. 싱글턴 패턴과의 차이점
private 생성자는 싱글턴(Singleton) 패턴에서도 사용됩니다. 하지만 목적은 정반대입니다. 싱글턴 패턴은 클래스의 인스턴스를 단 하나만 생성하여 공유하는 것이 목적이지만, 여기서 설명하는 방법은 인스턴스를 하나도 생성하지 않는 것이 목적입니다. 두 방법 모두 private 생성자를 사용하지만, 그 의도와 사용 방식에는 명확한 차이가 있다는 점을 이해하는 것이 중요합니다.
본론 3: 추상 클래스로는 인스턴스화를 막을 수 없을까?
어떤 개발자들은 인스턴스화를 막기 위해 추상 클래스(abstract class)를 사용하는 것을 고려하기도 합니다. 추상 클래스는 그 자체로 인스턴스화될 수 없기 때문입니다. 하지만 이 방법은 좋은 해결책이 아닙니다.
추상 클래스는 본질적으로 상속을 위해 설계된 클래스입니다. 따라서 다른 클래스가 이 추상 클래스를 상속하여 인스턴스를 생성할 수 있습니다. 이는 유틸리티 클래스의 목적과 맞지 않으며, 사용자에게 혼란을 줄 수 있습니다. “이 클래스는 상속해서 사용해야 하는구나”라고 오해하게 만들 수 있기 때문입니다. 따라서, 단순히 인스턴스화를 막는 것이 목적이라면, 추상 클래스가 아닌 private 생성자를 사용하는 것이 훨씬 더 명확하고 올바른 방법입니다.
결론: 의도를 명확히 하는 코드를 작성하라
정적 메서드와 필드만을 담는 유틸리티 클래스는 객체 생성이 필요 없습니다. Effective Java 아이템 4는 이러한 클래스의 인스턴스화를 막기 위한 가장 효과적이고 명확한 방법으로 private 생성자를 사용할 것을 권장합니다. private 생성자는 컴파일 시점에 인스턴스화를 막아주고, 상속을 방지하며, 클래스의 설계 의도를 명확하게 전달하는 강력한 수단입니다.
코드를 작성할 때는 단순히 기능이 동작하게 만드는 것을 넘어, 다른 개발자들이 코드를 오해 없이 올바르게 사용할 수 있도록 설계 의도를 명확하게 드러내는 것이 중요합니다. 유틸리티 클래스에 private 생성자를 추가하는 것은 이러한 좋은 설계 원칙을 실천하는 간단하면서도 효과적인 방법입니다. 여러분의 코드에 불필요하게 인스턴스화될 수 있는 유틸리티 클래스가 있다면, 지금 바로 private 생성자를 추가하여 코드의 안정성과 명확성을 한 단계 높여보세요.