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

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

• 문자열(String)은 텍스트를 표현하도록 설계되었고, 그 일을 아주 멋지게 해낸다.

  • 그런데 문자열은 워낙 흔하고 자바가 또 잘 지원해주어 원래 의도하지 않은 용도로도 쓰이는 경향이 있다.

• 많은 사람이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용한다.

  • 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는게 좋다.

  • 받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다.

  • 일반화해 이야기하자면, 기본 타입이든 참조 타입이든 적절한 값 타입이 있다면 그것을 사용하고, 없다면 새로 하나 작성하라

---

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

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

---

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

• 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않은 생각이다.
  • ex) 아래의 예제를 보자. [혼합 타입을 문자열로 처리한 부적절한 예]

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

• 위 방식은 단점이 많다.

  • 혹여라도 두 요소를 구분해주는 문자 #이 두 요소중 하나에서 쓰였다면 혼란스러운 결과를 초래한다.

  • 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다.

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

    • 그래서 차라리 전용 클래스를 새로 만드는 편이 낫다.

    • 이런 클래스는 보통 private 정적 멤버 클래스로 선언한다.

---

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

• 권한(capacity)을 문자열로 표현하는 경우가 종종 있다.

  • ex) 스레드 지역변수 기능을 설계한다고 가정해보자.

  • 그 이름처럼 각 스레드가 자신만의 변수를 갖게 해주는 기능이다.

  • 자바가 이 기능을 지원하기 시작한 때는 자바 2부터, 그 전에는 프로그래머가 직접 구현해야 했다.

    • 그 당시 이 기능을 설계해야 했던 여러 프로그래머가 독립적으로 방법을 모색하다가 종국에는 똑같은 설계에 이르렀다.

    • 바로 클라이언트가 제공한 문자열 키로 스레드별 지역변수를 식별한 것이다.

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

public class ThreadLocal {
    private ThreadLocal() { } // 객체 생성 불가
    
    // 현 스레드의 값을 키로 구분해 저장한다.
    private 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();
}

• 하지만 위 코드에서는 get으로 얻은 Object를 실제 타입으로 형변환해 써야 해서 타입 안전하지 않다.

• 처음의 문자열 기반 API는 타입안전하게 만들 수 없으며, Key를 사용한 API도 타입안전하게 만들기 어렵다.

  • 하지만 아래와 같이 ThreadLocal을 매개변수화 타입으로 선언하면 간단하게 문제가 해결된다.

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

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

• 위 코드는 문자열 기반 API의 문제를 해결해주며, 키 기반 API보다 빠르고 우아하다.

---

더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면, 문자열을 쓰고 싶은 유혹을 뿌리쳐라.

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

문자열을 잘못 사용하는 흔한 예로는 기본 타입, 열거 타입, 혼합 타입이 있다.

참조 - 이펙티브 자바 3/E - 조슈아 블로크때