[이펙티브자바] Item 62. 다른 타입이 적절하다면 문자열 사용을 피하라

문자열은 잘못 사용하면 번거롭고, 덜 유연하고, 느리고, 오류 가능성도 크다.

 

문자열은 워낙 흔하고, 자바가 잘 지원해주어 쉽게 쓸 수 있지만, 원래 의도하지 않은 용도로 쓰이는 경향이 있다.

 

🚫 문자열을 쓰지 않아야 하는 사례

기본 타입이든 참조 타입이든 적절한 값 타입이 있다면 그것을 사용하고, 없다면 새로 하나 작성하라.

문자열은 다른 값 타입을 대신하기에 적합하지 않다. 따라서 입력받을 데이터가 진짜! 문자열일 때만 문자열로 받는다.

받은 데이터가 수치형이라면 -> int, float, BigInteger

예/아니오 질문의 답이라면 -> boolean이나 적절한 열거 타입

 

문자열은 열거 타입을 대신하기에 적합하지 않다.

상수를 열거할 때는 문자열보다 열거 타입이 월등히 낫다.

 

문자열은 혼합 타입을 대신하기에 적합하지 않다.

String compoundKey = className + "#" + i.next();

와 같은 문자열은 큰 취약점이 있다.

만약 className이나 i.next()에 '#'이 포함되어 있다면 각 요소를 개별로 접근하려면 문자열을 파싱해야 하는 문제가 있다.

이렇게 접근한다면

- 모든 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다. 

- equals, toString, compareTo 메서드를 제공할 수 없다. String이 제공하는 기능에만 의존해야 한다.

이러한 상황일 땐 보통 private 정적 멤버 클래스로 새로 만드는 것이 낫다.

 

문자열은 권한을 표현하기에 적합하지 않다.

예를 들어 스레드 지역변수 기능을 설계해보자. (각 스레드가 자신만의 변수를 갖게 해주는 기능이다.)

총 4단계에 거쳐 설계를 진행한다.

 

첫 번째, 클라이언트가 제공한 문자열 키로 스레드별 지역변수를 식별한 방법이다.

/* 문자열을 사용해 권한을 부여한다. */
public class ThreadLocal {
	private ThreadLocal() { } // 객체 생성 불가
    
    // 현 스레드의 값을 키로 구분해 저장한다.
    public static void set(String key, Object value);
    
    // (키가 가리키는) 현 스레드의 값을 반환한다.
    public static Object get(String key);
}

여기서 문제점,

• 스레드 구분용 문자열 키가 전역 이름공간에서 공유된다.
  • 클라이언트가 고유한 키를 제공해야 가능한데, 의도치 않게 두 클라이언트가 같은 변수를 공유하게 될 수도 있다.
• 보안이 취약하다.
  • 악의적인 클라이언트라면 의도적으로 같은 키를 사용하여 다른 클라이언트의 값을 가져올 수 있다.

 

따라서 두 번째 설계로, 문자열 대신 위조할 수 없는 키를 사용한다. 이 키를 권한(capacity)라고 한다.

/* Key 클래스로 권한을 구분했다. */
public class ThreadLocal{
	private ThreadLocal(){ }  // 객체 생성 불가
    
    public static class Key{  // (권한)
    	Key() { }
    }
    
    //위조 불가능한 고유 키를 생성한다.
    public static Key getKey(){
    	return new Key();
    }
    
    public static void set(Key key, Object value);
    public static Object get(Key key);
}

이 방법은 문자열 기반 API의 문제를 해결해주지만, 더 개선할 수 있다.

• set과 get은 정적 메서드일 이유가 없으니 Key클래스의 인스턴스 메서드로 변경한다.
  • 그러면 이제 Key는 더 이상 스레드 지역변수를 구분하기 위한 키가 아니라, 그 자체가 스레드 지역변수가 된다.
• 결과적으로 ThreadLocal은 별달리 하는 일이 없으므로 중첩 클래스 Key의 이름을 ThreadLocal로 변경한다.

 

이렇게 리팩터링을 진행하면 세 번째로, 다음과 같은 코드를 얻을 수 있다.

/* 리팩터링하여 Key를 ThreadLocal로 변경 */
public final class ThreadLocal{
	public ThreadLocal();
    public void set(Object value);
    public Object get();
}

 

하지만 이 방법도 위에서 언급했던 '형변환'이 진행된다.

Object를 실제 타입으로 형변환해 써야 해서 타입안전하지 않다.

따라서 네 번째 설계로, ThreadLocal을 매개변수화 타입으로 선언하면 문제를 해결할 수 있다.

/* 매개변수화하여 타입안전성 확보 */
public final class ThreadLocal<T>{
	public ThreadLocal();
    public void set(T value);
    public T get();
}

 

이렇게 설계한 클래스는 자바의 java.lang.ThreadLocal과 흡사해졌다!

문자열 기반 API의 문제를 해결해주며, 키 기반 API보다 빠르고 우아한 코드가 완성되었다.

 

📚 정리하자!

더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면, 문자열을 쓰고 싶은 유혹을 뿌리쳐라!
문자열은 잘못 사용하면 번거롭고, 덜 유연하고, 느리고, 오류 가능성도 크다.
문자열을 잘못 사용하는 흔한 예로는 기본 타입, 열거 타입, 혼합 타입이 있다.