TIL
  • Contents
  • Book
    • 도메인 주도 설계
      • 1. 동작하는 도메인 모델 만들기
    • 오브젝트
      • 데이터 중심 설계
      • 책임 중심 설계
      • 책임 할당을 위한 GRASP 패턴
      • 메시지와 인터페이스
      • 객체 분해
    • Effective Java
      • Item 7 - 다 쓴 객체 참조를 해제하라
      • Item 7 발표 내용
      • Item 13 - clone 재정의는 주의해서 진행하라
      • Item 13 발표 내용
      • Item 16 - public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
      • Item 16 발표 내용
      • Item 26 - 로 타입은 사용하지 말라
      • Item 28 - 배열보다는 리스트를 사용하라
      • Item 28 발표 내용
      • Item 29 - 이왕이면 제네릭 타입으로 만들라
      • Item 30 - 이왕이면 제네릭 메서드로 만들라
      • Item 31 - 한정적 와일드 카드를 사용해 API 유연성을 높이라
      • Item 35 - ordinal 메서드 대신 인스턴스 필드를 사용하라
      • Item 37 - ordinal 인덱싱 대신 EnumMap을 사용하라
      • Item 37 발표 내용
      • Item 43 - 람다보다는 메서드 참조를 사용하라
      • Item 43 발표 정리
      • Item 56 - 공개된 API 요소에는 항상 문서화 주석을 작성하라
      • Item 56 발표 정리
      • Item 62 - 다른 타입이 적절하다면 문자열 사용을 피하라
      • Item 62 발표 정리
      • Item 73 - 추상화 수준에 맞는 예외를 던지라
      • Item 83 - 지연 초기화는 신중히 사용하라
      • Item 83 발표 내용
      • Item 89 - 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
      • Item 89 발표 내용
    • 개발자를 위한 SQL 튜닝
      • SQL 쿼리 실습을 위한 DB 서버 구축
      • 인덱스 튜닝
      • 인덱스 스캔 튜닝
      • 인덱스 스캔 튜닝 실습
      • 인덱스 패스트 풀 스캔
      • 테이블 풀 스캔 튜닝
      • 조인 튜닝
      • 중첩 루프 조인 튜닝
      • 중첩 루프 조인 튜닝 실습
      • 해시 조인 튜닝
      • 해시 조인 튜닝 실습
      • 세미 조인 튜닝
      • 세미 조인 튜닝 실습
      • 아우터 조인
      • 함수 튜닝
      • 부분 범위 처리 튜닝
      • 파티셔닝 튜닝
      • 파티션 인덱스 튜닝
      • 병렬 처리 튜닝
  • Java
    • Design Pattern
      • Intro
      • Types of Design Patterns
      • Creational
        • Builder Pattern
        • Singleton Pattern
        • Prototype Pattern
        • Factory Pattern
        • Abstract Factory Pattern
      • Structural
        • Adapter Pattern
        • Bridge Pattern
        • Composite Pattern
        • Decorator Pattern
        • Facade Pattern
        • Flyweight Pattern
        • Proxy Pattern
      • Behavioural
        • Chain of Responsibility Pattern
        • Command Pattern
        • Interpreter Pattern
        • Iterator Pattern
        • Mediator Pattern
        • Memento Pattern
        • Observer Pattern
        • State Pattern
        • Strategy Pattern
        • Template Method Pattern
        • Visitor Pattern
    • Java
      • Cracking the Coding Interview
      • TDD, Clean Code with Java 11기
        • 자동차 레이싱
        • 로또
        • 사다리 타기
        • 볼링 게임 점수판
    • 궁금증
      • 자바 8 버전의 인터페이스와 추상클래스
      • 자바의 제네릭은 어떻게 이전 버전과 호환되는 걸까?
      • 스프링 MVC 기본 구조
      • 마샬링과 직렬화
      • 인터뷰 질문 모음
      • Code Coverage
  • Database
    • Database
      • SQL 레벨업
      • DB 스터디
        • DBMS
          • MySQL
        • INDEX
        • Join(Nested Loop, Hash)
        • Join(Semi, Outer)
        • Partial Range Processing
        • Function
        • Partitioning
        • Parallel Processing
  • Network
  • Architecture
    • Issue
      • Git Push Error
      • SonarLint Warning - assertThatExceptionOfType()
  • Infra
  • Spring
    • Spring JPA
      • 1. 데이터 모델링 및 연관관계 설정
      • 2. 최적화 내용
      • 3. Spring-Data-Jpa
      • 4. Query DSL
    • Spring Security
      • Intro
    • Spring Batch
      • 배치용 디비 설치
      • 배치 데이터 분석하기
      • 배치 프로세스 구상하기 및 성능 차이 확인하기
  • Issue
  • Tistory
    • Tistory Blog
  • Design High Performing Architectures
  • Design Resilient Architectures
  • Design Secure Applications And Architectures
  • Design Cost-Optimized Architectures
Powered by GitBook
On this page
  • Intro
  • 문자열은 다른 값 타입을 대신하기에 적합하지 않다.
  • 문자열은 열거 타입을 대신하기에 적합하지 않다.
  • 문자열은 혼합 타입을 대신하기에 적합하지 않다.
  • 문자열은 권한을 표현하기에 적합하지 않다.
  • 권한을 문자열로 관리하는 ThreadLocal 예시

Was this helpful?

  1. Book
  2. Effective Java

Item 62 - 다른 타입이 적절하다면 문자열 사용을 피하라

다른 타입이 적절하다면 문자열 사용을 피하라

PreviousItem 56 발표 정리NextItem 62 발표 정리

Last updated 3 years ago

Was this helpful?

Intro

  • 다양한 데이터 타입을 문자열로 표현 할 수 있다.

  • 하지만 데이터 타입을 문자열로 관리하는 것은 좋지 않다.

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

  • 파일, 네트워크, 키보드의 입력으로부터 데이터를 받을 때 문자열을 사용할 수 있다.

  • 입력받을 데이터가 진짜 문자열일 때만 사용하는 것이 좋다.

  • 입력 받은 데이터의 타입

    • 수치형인 경우 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다.

    • 예 / 아니오 질문의 답인 경우 열거 타입이나 boolean 타입으로 변환해야 한다.

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

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

  • 상수를 열거 하는 경우 문자열보다는 열거 타입이 월등히 낫다.

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

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

  • 데이터베이스에서 복합 속성과 같은 사례

  • ex) 전화번호

    • 지역번호-국번호-가입자개별번호

  • 두 요소를 구분해주기 위한 구분자(delimiter or separator)가 요소 안에서 사용되는 경우 혼란스러운 결과를 초래한다.

    • 이를 해결 하기 위해서 각 요소에 접근하여 문자열을 확인해야 하는 부가적인 기능이 생긴다.

    • 결국에는 데이터 타입을 관리하기 위한 클래스가 생기는 문제점이 생긴다.

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

  • 권한(capacity)을 문자열로 표현하는 경우 보안이 취약해지며 의도적으로 같은 키를 사용하여 값을 탈취하는 문제점이 생길 수 있다.

권한을 문자열로 관리하는 ThreadLocal 예시

public class ThreadLocal {
    private ThreadLocal() {
    }

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

    // (키가 가리키는) 현 스레드의 값을 반환한다.
    public static Object get(String key);
}
  • 스레드 구분용 문자열 키가 전역 이름 공간에서 공유된다는 문제점

  • 두 클라이언트가 서로 소통하지 못해 같은 키를 쓰기로 결정했다면, 의도하지 않게 같은 변수를 공유하게 된다.

이를 해결하기 위해서 API는 문자열 대신 위조할 수 없는 키를 사용하면 된다.

  • 이 키를 권한(capacity)라 한다.

public class ThreadLocal {
    private ThreadLocal() {
    }

    public static class Key { // (권한)
        Key() {
        }
    }

    public staatic getKey() {
        return 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를 실제 타입으로 형변환해 써야 해서 타입 안전하지 않다.

  • ThreadLocal을 매개변수화 타입으로 선언하여 문제를 해결한다.

    • java.lang.ThreadLocal처럼 구성하여 문자열 기반 API의 문제를 해결

public final class ThreadLocal<T> {
    public ThreadLocal();

    public void set(T value);

    public T get();
}
Presentation