(이펙티브 자바) 규칙 62. 다른 타입이 적절하다면 문자열 사용을 피하라

(Effective Java) 규칙 62. 다른 타입이 적절하다면 문자열 사용을 피하라

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

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

---

문자열의 남용

---

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

  • 많은 경우 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용함
  • 자연스러워 보이긴 하지만 입력받을 데이터가 진짜 문자열 일때만 그렇게 하는 게 좋음

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

  • 입력 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 함
  • '예/아니오' 질문의 답이라면 적절한 열거 타입이나 boolean 으로 변환해야 함

 

문자열이 적합하지 않은 경우

---

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

• 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 나음 (규칙 34)

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

• 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않은 생각임

  //혼합 타입을 문자열로 처리한 부적절한 예
  String compoundKey = className + "#" + i.next(); 

  • 단점이 아주 많은 방식
    • 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커짐
    • 적절한 equals, toString, compareTo 메서드를 제공할 수 없으며, String이 제공하는 기능에만 의존해야 함
  • 차라리 전용 클래스를 새로 만드는 편이 나음
    • 이런 클래스는 보통 private 정적 멤버 클래스로 선언함 (규칙 24)

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

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

• 예) 스레드 지역변수 기능 설계

  • 각 스레드가 자신만의 변수를 갖게 해주는 기능 (자바가 이 기능을 지원하기 시작한 때는 자바 2부터로 이전에는 직접 구현했어야 함)
  • 당시 여러 프로그래머가 방법은 모색하다가 똑같은 설계가 탄생함
    • 클라이언트가 제공한 문자열 키로 스레드별 지역변수를 식별한 것

    public class ThreadLocal {
        private ThreadLocal() {  }  //객체 생성 불가
    
        //현 스레드의 값을 키로 구분해 저장한다.
        public static void set(String key, Object value);
    
        //(키가 가리키는) 현 스레드의 값을 반환한다. 
        public static Object get(String 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로 바꿀수 있음

• 위 예제는 아래와 같이 개선이 가능하다.

  public final class ThreadLocal {
      public ThreadLocal();
      public void set(Object value); 
      public Object get();
  }

  • 이 API에서는 get으로 얻은 Object를 실제 타입으로 형변환해 써야 해서 타입 안전하지 않음

• 위 예제는 제네릭을 사용하여 문제 해결할 수 있다.

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

 

결론

---

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

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

 

---

끝으로

이 글이 도움이 되었다면, 하단의 Google 광고 👎👎👎 한번씩 클릭 부탁 드립니다. 🙏🙏🙏

광고 클릭은 많은 힘이 됩니다!