아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

[JoisFe]

아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

정적 메서드와 정적 필드만을 담은 클래스를 만들어야 하는 경우

• 객체 지향과는 거리가 먼 클래스 방식임 (남용은 금물!)
  --> 그러나 이러한 클래스가 나름의 쓰임새가 있음

이러한 클래스를 Util 클래스라 부른다. (정적 멤버만 담은 클래스)

Util 클래스 사용 경우

1. java.lang.Math, java.util.Arrays
   -> 기본 타입 값 or 배열 관련 메서드를 모아놓은 클래스
2. java.util.Collections
   -> 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓은 클래스
3. final 클래스와 관련한 메서드를 모아놓는 경우
   -> final 클래스를 상속해서 하위 클래스에 메서드를 넣는 것이 불가능

Util 클래스 사용의 주의 사항

• Util 클래스는 인스턴스로 만들어 사용하기 위해 설계된 것이 아님!

하지만 생성자를 명시하지 않으면 컴파일러는 자동으로 기본 생성자를 만듬

public static UtilClass {
	private static int num;

//	public UtilClass() {} --> 자동 생성

	private static void staticMethod() {}
}

• 의도치 않게 인스턴스화 할 가능성이 있음

추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없음 !!!

• 또한 사용자는 상속해서 쓰라는 뜻으로 오해할 가능성이 있음 --> (아이템 19 참고)

인스턴스화를 막는 방법

private 생성자를 추가하자

public static UtilClass {
        private static int num;

        // 기본 생성자가 만들어지는 것을 막음 (인스턴스화 방지)
	private UtilClass() {}

	private static void staticMethod() {}
}

명시적 생성자인 private을 만들어줌으로 써 클래스 바깥에서 접근이 불가능 (생성자가 존재하는데 호출할 수 없다는 것이 직관적이지 않으니 주석으로 의미를 더해주자)

• 어떠한 환경에서도 클래스가 인스턴스화 되는 것을 막아줌
• 상속을 불가능하게 하는 효과도 있음
• 모든 생성자는 명시적이든 묵시적이든 상위 클래스 생성자 호출 --> private으로 선언 하여 하위 클래스가 상위 클래스의 생성자에 접근하는 길도 막음

[JoisFe]

정리에 소질이 없어 읽기에 편하실지 모르겠네요.. 정리하는 법도 계속해서 늘려나가도록 하겠습니다.
잘못된 부분이나 질문 있으시면 comment 주세요.

[Irisation23]

• 객체 지향과는 거리가 먼 클래스 방식임 (남용은 금물!)
  --> 그러나 이러한 클래스가 나름의 쓰임새가 있음

• 유틸 클래스는 객체 지향이 지향하는 방향 중에 어떤 부분이 아쉬워서 남용이 불가능 하다고 하는지에 대해서 궁금합니다🧐

[jinan159]

제 생각부터 먼저 말씀드리면, '변경에 유연하지 않고 의존성을 효율적으로 통제할 수 없으며 테스트가 힘들기 때문이다' 입니다.

조영호님의 오브젝트에 의하면 객체지향 프로그래밍은 변경에 유연한 구조, 그리고 의존성을 효율적으로 통제할 수 있다는 장점이 있다고 합니다.
이런 관점에서 봤을 때 정적 필드, 메소드만 있는 클래스(이하 유틸 클래스)의 경우에는 변경에 유연한 구조가 되기 힘들 것 같습니다.

변경에 유연한 구조를 만들기 위해서는 OCP(확장에는 열려있고, 변경에는 닫혀있어야 한다)를 만족해야 하지만, 유틸 클래스는 이를 만족하지 못합니다.
먼저 '확장에는 열려있고' 를 생각해보면 static 한 요소들은 해당 클래스에 종속된 항목들로 자식 클래스에 상속되지 못하죠.
그래서 당연히 자식 클래스에서 오버라이딩(확장)이 불가능 합니다.
그리고 '변경에는 닫혀있어야 한다' 는 일단 만족한다고 볼수도 아니라고 볼수도 있습니다.

interface Strategy { ... }

class Util {
    private static Strategy strategy;

    private Util() {}

    public static void utilMethod() { ... }
    public static void setStrategy(Strategy strategy) { this.strategy = strategy }
}

// 외부 로직
Util.setStrategy(new DefaultStrategy());
Util.utilMethod();

이렇게 변경될만한 요소(전략, Strategy)를 외부에서 주입받아 변경에 닫혀있게 되었습니다.
그리고 외부 로직에서 '의존성'을 주입하여 유틸 클래스는 Strategy 구현체에 신경쓰지 않는 구조를 만들어 냈습니다.

하지만 여기서 문제는 setter 가 public 이기 때문에 strategy 를 누구나 변경할 수 있습니다.
이는 동작의 일관성을 해칠 위험이 있죠.
그래서 immutable 클래스를 만들기 위해 final 키워드를 붙인다면 다음과 같이 변합니다.

interface Strategy { ... }

class Utils {
    private static final Strategy strategy = new DefaultStrategy();

    private Utils() {}

    public static void utilMethod() { ... }
}

Utils.utilMethod();

이렇게 되면 '변경에는 닫혀있어야 한다' 는 원칙을 어기게 됩니다.
결국 유틸 클래스는 변경에 유연한 구조 와 의존성을 효율적으로 통제할 수 있다는 객제지향의 장점을 살리지 못하게 됐죠.
이런 구조는 테스트 코드를 작성할때도 불편함을 야기합니다.

예를들어 DefaultStrategy 는 무거운 작업이라, 대신에 테스트 코드에서는 MockStrategy 를 사용하려고 합니다.
하지만 테스트 코드에서는 Utils 클래스 내부의 DefaultStrategy 를 MockStrategy 로 바꿀 방법이 없습니다.
(리플렉션을 이용해서 억지로는 가능하지만, 좋은 방법은 아니라고 생각합니다.)

이러한 이유들 때문에 객체 지향 관점에서 유틸 클래스를 남용하지 마라고 한다고 생각합니다.