[Effective Java] item 62. 다른 타입이 적절하다면 문자열 사용을 피하라

[Effective Java] item 62. 다른 타입이 적절하다면 문자열 사용을 피하라

문자열을 쓰지 말아야 할 사례

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

많은 사람이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용한다. 사뭇 자연스러워 보이지만, 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는게 좋다.
받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다. '예/아니오' 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 한다.
일반화해 이야기하자면, 기본 타입이든 참조 타입이든 절절한 값 타입이 있다면 그것을 사용하고, 없다면 새로 하나 작성하라. 당연한 조언 같겠지만, 지켜지지 않는 경우가 많아서 하는 이야기다.

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

아이템 34에서 이야기했듯, 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 낫다.

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

여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않은 생각이다. 예를 들어 다음은 실제 시스템에서 가져온 코드다.

혼합 타입을 문자열로 처리한 부적절한 예

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

이는 단점이 많은 방식이다. 혹여라도 두 요소를 구분해주는 #이 두 요소중 하나에서 쓰였다면 혼란스러운 결과를 초래한다. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다. 적절한 equals, toString, compareTo 메서드를 제공할 수 없으며, String이 제공하는 기능에만 의존해야 한다. 그래서 차라리 전용 클래스를 새로 만드는 편이 낫다. 이런 클래스는 보통 private 정적 멤버 클래스로 선언해야 한다.

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

권한(capacity)를 문자열로 표현하는 경우가 종종 있다. 예를 들어 스레드 지역변수 기능을 설계한다고 해보자. 그 이름처럼 각 스레드가 자신만의 변수를 갖게 해주는 기능이다. 자바가 이 기능을 지원하기 시작한 때는 자바 2부터로, 그 전에는 프로그래머가 직접 구현해야 했다. 그 당시 이 기능을 설계해야 했던 여러 프로그래머가 독립적으로 방법을 모색하다가 종국에는 똑같은 설계에 이르렀다. 바로 클라이언트가 제공한 문자열 키로 스레드별 지역변수를 식별한 것이다.

잘못된 예 - 문자열을 사용해 권한을 구분하였다.

public class ThreadLocal {
    private ThreadLocal() {} // 객체 생성 불가

    // 현 스레드의 값을 키로 구분해 저장한다.
    public static void set(String key, Object value);

    // (키가 가리키는) 현 스레드의 값을 반환한다.
    public static Object get(String key);
}

이 방식의 문제는 스레드 구분용 문자열 키가 전역 이름공간에 공유된다는 점이다. 이 방식이 의도대로 동작하려면 각 클라이언트가 고유한 키를 제공해야 한다. 그런데 만약 두 클라이언트가 서로 소통하지 못해 같은 키를 쓰기로 결정한다면, 의도치 않게 같은 변수를 공유하게 된다. 결국 두 클라이언트 모두 제대로 기능하지 못할 것이다. 보안도 취약하다. 악의적인 클라이언트라면 의도적으로 같은 키를 사용하여 다른 클라이언트의 값을 가져올 수도 있다.

이 API는 문자열 대신 위조할 수 없는 키를 사용하면 해결된다. 이 키를 권한(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();
}

이 API는 get으로 얻은 Object를 실제 타입으로 형변환해 써야 해서 타입 안전하지 않다. 처음의 문자열 기반 API는 타입안전하게 만들 수 없으며, Key를 사용한 API도 타입안전하게 만들기 어렵다. 하지만 ThreadLocal을 매개변수화 타입(아이템 29)으로 선언하면 간단하게 문제가 해결된다.

매개변수화하여 타입안전성 확보

public final class ThreadLcoal<T> {
    public ThreadLocal();
    public void set(T value);
    public T get();
}

이제 자바의 java.lang.ThreadLocal과 흡사해졌다. 문자열 기반 API의 문제를 해결해주며, 키 기반 API보다 빠르고 우아하다.

핵심정리

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

참고 자료

• Effective Java 3/E