[Item 62] 다른 타입이 적절하다면 문자열 사용을 피하라
문자열을 쓰지 않아야 할 사례를 살펴보자.
문자열을 쓰지 않아야 할 사례
- 문자열은 다른 값 타입을 대신하기에 적합하지 않다.
- 받은 데이터가 수치형이면 int, float, BigInteger 등 적당한 수치타입으로 변환해야 하고, '예/아니오' 질문의 답이라면 적절한 열거 타입이나 boolean 타입으로 변환해야 한다.
- 기본타입이든 참조타입이든 적절한 값 타입이 있다면 그것을 사용하고, 없다면 새로 하나 작성하는 것이 좋다.
- 문자열은 열거 타입을 대신하기에 적합하지 않다.
- 상수를 열거 할 때는 문자열보다는 열거 타입이 월등히 낫다.
- 문자열은 혼합 타입을 대신하기에 적합하지 않다.
- 여러 요소가 혼합된 데이터를 하나의 문자열을 표현하는 것은 좋지 않은 생각이다.
- String Key = className + "#" + i.next(); 코드와 같이 두 요소를 구분해 주는 특수문자를 사용한다면, 각 요소를 개별로 접근하려면 파싱해야 해서 느리고, 귀찮고, 오류가능성이 커진다. 적절한 equals, toString, compareTo 메서드를 제공할 수 없으며, String이 제공하는 기능만 의존해야 한다. 그래서 차라리 전용 클래스를 새로 만드는 편이 낫다.
- 문자열은 권한을 표현하기에 적합하지 않다.
- 다음의 사례는 코드의 예시를 살펴보자.
문자열은 권한을 표현하기에 적합하지 않다 - 잘못된 예시
public class ThreadLocal {
private ThreadLocal() {} //객체 생성 불가능
//현 스레드의 값을 키로 구분해 저장한다.
public static void set (String key, Object value);
//(키가 가리키는) 현 스레드의 값을 반환한다.
public static Object get(String key);
}
이 방식의 문제는 스레드 구분용 문자열 키가 전역 이름공간에서 공유된다는 점이다.
의도대로 동작하려면 각 클라이언트가 고유한 키를 제공해야하는데, 만약 두 클라이언트가 서로 소통을 하지 않고 같은 키를 쓰기로 결정한다면, 의도치 않게 같은 변수를 공유하게 된다. 제대로 기능을 하지 못할 거고 보안도 취약해진다.
이 API는 문자열 대신 위조할 수 없는 키를 사용하면 해결된다.
문자열은 권한을 표현하기에 적합하지 않다 - 올바른 예시
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);
}
set과 get은 이제 정적 메서드일 이유가 없으니 Key 클래스의 인스턴스 메서드로 바꾸자. 이렇게 하면 Key는 더 이상 스레드 지역변수를 구분하기 위한 키가 아니라, 그 자체가 스레드 지역변수가 된다. 결과적으로 지금의 톱레벨 클래스인 ThreadLocal은 별달리 하는 일이 없어지므로 치워버리고, 중첩 클래스 Key의 이름을 ThreadLocal로 바꿔버리자.
다음은 리펙터링하여 Key를 ThreadLocal로 변경한 코드이다.
public final class ThreadLocal {
public ThreadLocal();
public void set(T value);
public Object get();
}
이 API에서는 get으로 얻은 Object를 실제 타입으로 형변환해 써야 해서 타입 안전하지 않다. 처음의 문자열 기반 API는 타입안전하게 만들 수 없으며, Key를 사용한 API도 타입안전하게 만들기 어렵다. 하지만 ThreadLocal를 매개변수화 타입으로 선언하면 해결이된다.
다음은 ThreadLocal를 매개변수화 타입으로 변경한 코드이다.
public final class ThreadLocal<T> {
public ThreadLocal();
public void set(T value);
public T get();
}
문자열 기반 API의 문제를 해결해주며 키 기반 API보다 빠르다.
핵심정리
- 더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면 문자열을 쓰지 말자.
참조자료
이펙티브 자바 3/E - 교보문고
프로그래밍인사이트 | 자바 6 출시 직후 출간된 『이펙티브 자바 2판』 이후로 자바는 커다란 변화를 겪었다. 그래서 졸트상에 빛나는 이 책도 자바 언어와 라이브러리의 최신 기능을 십분 활용
www.kyobobook.co.kr