Utility 클래스의 장단점

Utility 클래스

클래스 인스턴스를 생성하지 않고도 기존 코드 블록을 재사용할 수 있는 범용 클래스
static 클래스고 Stateless로 사용하여 멀티스레드 환경에서 Thread-safe하다.
보통 final로 선언되어 상속될 수 없고, 생성자는 private으로 선언되어 초기화 가능성을 막아버리며 다른 클래스에 의해 생성될 수 없다.

 

Utility 클래스의 장점

여러 클래스에서 공통적으로 사용되는 메서드를 모아서 관리하며 코드의 재사용성을 높인다.

 

 

Utility 클래스의 단점

1. Utility Class는 근본적으로 객체지향적인 프로그래밍 기법이 아니다.
Utility Class는 기능 분할에 익숙해져있는 절차적 프로그래밍에 가깝다.

2. Utility Class를 사용하는 클래스는 Utility Class에 강한 결합도를 갖게 된다. 
추상화를 진행하지 않았으므로 Utility Class의 변화에 결합도를 가진 객체는 많은 영향을 받는다. 따라서 Utility Class에 대한 변경이 생길때마다 클라이언트 측(해당 클래스)에서 수정이 필요하게 되면서 OCP를 위반하고 유지보수하기 힘들다.

 

 

Utility 클래스를 객체지향적으로 바꾸기

객체 지향 패러다임에서는 객체를 인스턴스화해서 행위를 구현해야 한다. Utility 클래스에서 추가적인 정적 메소드를 호출하는 대신, 요구하는 행동을 제공할 수 있는 객체를 생성해야 한다.
"객체 지향의 세계에서는 데이터라는 것은 없다. 객체와 그 행위만이 있다!"

 

절차적 메소드 호출은 다음과 같고,

int max = NumberUtils.max(10, 5);

객체 지향적인 방법은 다음과 같다.

public class Max implements Number {
  
  private final int a;
  private final int b;
  
  public Max(int x, int y) {
    this.a = x;
    this.b = y;
  }
  
  @Override
  public int intValue() {
    return this.a > this.b ? this.a : this.b;
  }
}

int max = new Max(10, 5).intValue();

 

 

메서드를 특정 클래스에 두기 모호한 경우, EmailValidator, EmailFormatter, EmailCreator, EmailSendor 등과 같은 적절한 이름을 사용하여 클래스를 분리하는 것이 좋다. 또한 TextUtils, ViewUtils, ArrayUtils처럼 하나의 Utility 클래스를 두는 것보다 별개의 행동을 가진 작은 클래스를 만드는 것이 좋다.

 

 

참고
Utils class good and/or bad?
객체지향 프로그래밍으로 유틸리티 클래스를 대체하자.