Java로 프로그래밍을 시작했을 때 switch 문이 문자열을 사용하지 않는다는 사실 때문에 좌절했습니다. 그런 다음 Enum을 사용하면 유형 안전 (쉽게 리팩토링을 제공함) 및 다른 개발자에게 명확함을 제공하는 대신 원시 값을 전달하지 않고 얻을 수있는 이점을 깨달았습니다.

SE7에서는 이제 열거 형이 아닌 입력으로 문자열이있는 스위치를 사용하기로 결정하는 상황을 생각하기 위해 고심하고 있습니다. 전체 문자열 (예 : 부분 또는 정규식 일치가 아닌)을 전환하여 구현하면 코드를 변경할 이유가 적지 않은 것 같습니다.

그리고 IDE 도구와 코딩의 읽기 / 쓰기 비율을 사용하면 문자열 값을 전달하는 것보다 추가 Enum을 자동 생성하는 것이 훨씬 더 좋습니다.

프로그래머로서 우리에게 어떤 이점이 있습니까? 보일러 플레이트가 적습니까?

언어가이 기능에 대해 울부 짖는 느낌이 들지 않습니다. 어쩌면 내가 간과하는 유스 케이스가있을 수 있습니다.

내가 알 수있는 한, 질문은 문자열 상수를 열거 형으로 래핑하는 것이 언어 사용자의 요구를 충족시키기에 충분하지 않은 이유입니다. 이는 JDK 7 (프로젝트 코인) 메일 링리스트에서 발표 된 공식 기능 제안 에서 다루어졌습니다 .

제안서를 읽은 결과 열거 형을 사용하는 대안이 유형 팽창을 소개한다는 근거로 기각되었습니다. 사용자의 편의를 위해 제안의 관련 부분에서 인용 열거 형 주소 지정 문 아래 인용 대담한 :

주요 장점 : 제안이 유리한 변화를 만드는 것은 무엇입니까?

더 일정한 코딩 패턴은 일정한 문자열 값 세트에 기초하여 선택된 연산에 사용될 수있다. 새로운 구조의 의미는 Java 개발자에게 분명해야합니다.

주요 혜택 : 제안이 채택되면 플랫폼이 더 나은 이유는 무엇입니까?

문자열 기반 디스패치 코드의 성능이 향상 될 수 있습니다.

주요 단점 : 항상 비용이 있습니다.

컴파일러의 구현 및 테스트 복잡성이 일부 증가했습니다.

대안 : 언어 변경없이 혜택과 장점을 얻을 수 있습니까?

아니; 문자열 동등성에 대한 체인 if-then-else 테스트는 잠재적으로 비싸며 관심있는 문자열 값 당 하나의 전환 가능한 상수에 대한 열거 형을 도입하면 좋은 원인없이 프로그램에 다른 유형을 추가합니다 ...

코드를 더 읽기 쉽게 만드는 것 외에도 if/else if비교에 비해 잠재적 인 성능 향상이 있습니다 . 변경이 가치가 있는지 여부는 비교할 횟수에 따라 다릅니다. 스트링 스위치는 두 개의 개별 스위치 명령으로 방출됩니다. 첫 번째는 해시 코드에서 작동하므로 lookupswitch궁극적으로 O(log n)복잡성을 초래 하는 경향이 있습니다 . 두 번째는 항상 완벽 O(1) tableswitch하므로 결합 된 복잡성은 여전히 ​​그렇습니다 O(log n). 하나의 선형 if/else if문 문장은 약간 더 O(n)복잡합니다.

예를 들어, 3 개 이상의 문자열을 비교하는 경우 a switch가 더 읽기 쉽고 컴팩트합니다. 핫 코드 경로에서 많은 수의 비교를 수행하지 않는 한 차이가 눈에 띄지 않지만 성능이 더 우수 할 수 있습니다.

enum값을 외부에서 가져올 때 ( 예 : 데이터베이스에 저장) 문자열 전환을 사용할 수 있습니다 .

JDK 7의 또 다른 주목할만한 점은 구성 switch보다 성능이 훨씬 뛰어납니다 if-else.

빠른 문자열 switches 의 좋은 사용 사례는 노드 및 속성 유형을 많이 전환해야 할 때 JSON / XML 스트림 구문 분석 일 수 있습니다. 더 좋은 옵션을 생각할 수 없습니다.

간단

Switch in String 지원은 열거 형 또는 if-else논리로 변환하지 않고 데이터를 처리하는 데 유용합니다 . 때로는 문자열을 켜는 것이 더 쉽습니다.

에서 JDK 7 (프로젝트 동전) 메일 링리스트에서 기능 제안 ( @gnat 대답 )

관심있는 문자열 값 당 하나의 전환 가능한 상수에 대한 열거 형을 도입하면 좋은 원인없이 프로그램에 다른 유형을 추가 할 수 있습니다 ...

그렇지 않은 경우 버전

이것은 짧지 만 많은 사람들 if's이 읽기가 어렵습니다. 그리고 이것은 느립니다.

if (color.equals("red")) {
    System.out.println("Color is Red");
} else if (color.equals("green")) {
    System.out.println("Color is Green");
} else {
    System.out.println("Color not found");
}

열거 형 버전

열거 형을 정의해야하며, 이것은 좋지만 때로는 필요하지 않습니다.

enum Color {RED, GREEN}

평소와 같이 처리

try {
    switch (Color.valueOf(color)) {
        case RED:
            System.out.println("Color is Red");
            break;
        case GREEN:
            System.out.println("Color is Green");
            break;
    }
} catch (IllegalArgumentException e) {
    System.out.println("Color not found");
}

JDK 7-스위치 명령문 버전의 문자열

추가 유형을 변환하고 정의하지 않고도 처리 할 수 ​​있습니다.

switch (color) {
    case "red":
        System.out.println("Color is Red");
        break;
    case "green":
        System.out.println("Color is Green");
        break;
    default:
        System.out.println("Color not found");
}

모든 언어에서 개선 된 부분은 코드를보다 쉽게 ​​읽을 수 있도록하는 것입니다. 나는 언젠가 공상보다 읽기 쉬운 코드를 선호합니다.

이것을 믿을 수는 없지만 시도해보십시오.

public enum JettStaff {
  ADRIAN("Adrian German") {
    public String toString() {
      return name + " (dgerman@indiana.edu)";
    }
  },
  ARJIT("Arjit Sengupta") {
    public String toString() {
      return name + " (asengupt@indiana.edu)";
    }
  },

  // and on for the rest...

  private String name;

  public JettStaff(String n) { this.name = n; }
}

JettStaff x = JettStaff.SUZANNE;
System.out.println(x);

열거 형은 훌륭하므로 가능하면 문자열 대신 사용해야합니다. 그러나 Java 외부에서 오는 외부 객체로 작업 해야하는 경우와 같이 때로는 불가능한 경우가 있습니다. 무언가를 파싱해야한다고 상상해보십시오. 서버 응답, 구성, 로그 파일 또는 이와 유사한 것 : 찾고있는 많은 옵션이 있으며 열거 형이 될 수있는 방법이 없습니다. Java <7에서는 여러 가지 문제가 발생합니다.

  if (something.equals("foo")) {
    // foo processing
  } else 
  if (something.equals("bar")) {
   // bar processing
  }

이 경우 이름으로 가져 오거나 사용자 정의 문자열-> 열거 루틴을 제공하여 열거 형을 계속 사용할 수 있지만 때로는 불가능하거나 실용적이지 않습니다 (예 : 너무 많은 열거 형을 만들어야 할 때)

TLDR : 순수하게 Java 코드로 작업 할 때 반드시 Enum 을 사용해야하지만 항상 외부 객체로 가능하지는 않습니다. 내 설명이 이해되기를 바랍니다.

Stringsswitch 문에 사용할 때 코드가 깨끗하고 읽기 쉽다는 의견에 동의하지 않으며 프로그래밍이 잘못되었다고 생각합니다. 저장하는 데 사용하는 값을 변경하면 모든 스위치 또는 if-elseif 발생마다 값을 변경해야합니다. 하드 코드 된 값을 코드의 모든 Bir에 넣기 때문에 좋지 않습니다. 언젠가이 하드 코딩 된 값 중 하나를 변경하기로 결정한 경우 어떻게 하시겠습니까? 모든 사본을 검색하고 교체 하시겠습니까?

if-elseif 문을 수행하는 일부 하드 코딩 된 값이있는 경우 상수 안전 값을 사용하는 것이 Java 1.5 이전에는 유형 안전성을 가져 오기 때문에 훨씬 좋습니다.

좋아, HTTP 요청, 파일 등에서 String 값을 얻는 상황이있을 수 있으며 원시 값으로 변환하는 것은 많은 고통입니다. 그러나이 Enum시점에서 좋은 일을한다. Enum에 저장 한 값을 변경하려면 선언 할 때 변경하면됩니다. 코드에서 다른 것을 변경할 필요가 없습니다. (물론 다른 곳에 저장된 값을 변경해야합니다).

더럽고 게으른 코드를 구현하는 것만으로도 완벽합니다. 많은 코드를 작성하고 싶지는 않지만 Enum대규모의 복잡한 소프트웨어를 사용하면 죽일 수 있습니다.

어떤 정보가 들어오는 지 알고 5 개 상태 일 수 있다는 것을 알고 있다면 Enum. 그러나 가능한 상태가 9000 이상이고 42 만 찾으면 스위치를 사용하는 것이 좋습니다. 모든 상태를 입력하고 싶지 않기 때문입니다.

Enum은 가능한 상태를 알 수 없거나 많지 않고 몇 가지만 신경 쓰지 않는 한 대부분의 환경에서 대부분 선택하는 경향이 있습니다.

그런데 왜 그들이 지금 소개 했습니까? 더 깨끗한 코드를 허용 한 변경 일뿐입니다.

1.5에서는 Enum에 대한 사용자 지정 본문을 만들 수도 있습니다.