[SPRING] Java는 변경 가능성을 보여줍니다.

Java는 변경 가능성을 보여줍니다.

나는 그것을 아는 유일한 사람인지는 모르겠지만 열거 형의 값은 암시 적으로 최종적이지 않으며 수정할 수 있습니다.

  enum EnumTest {
    TOTO("TOTO 1"),
    TATA("TATA 2"),
    ;

    private String str;

    private EnumTest(String str) {
      this.str = str;
    }

    @Override
    public String toString() {
      return str;
    }
  }

  public static void main(String[] args) {
    System.out.println(EnumTest.TATA);
    EnumTest.TATA.str = "newVal";
    System.out.println(EnumTest.TATA);
  }

TATA 2
newVal

이 값들은 종종 인스턴스 생성 (TOTO ( "TOTO 1"))에서 초기화되지만 나 자신을 제외하고는 불변이어야하는 enum 변수의 최종 키워드를 사용하는 사람을 본 적이 없습니다. 그것은 질문의 요점이 아닙니다. 단지 내가 이것을 알고있는 유일한 사람인지 궁금합니다.

변경할 수있는 enum을 만드는 유스 케이스가 있다면 알고 싶습니다.

또한 우리가 열거 형으로 할 수있는 것의 한계를 알고 싶습니다 (우수 사례 또는 우수하지 않음). 테스트하지는 않았지만, 아마도 스프링 빈으로 enum을 주입 할 수 있을까? 적어도 우리는 각 인스턴스 (@Deprecated는 예제를 위해 잘 작동합니다)와 메소드에 주석을 달 수있는 것 같습니다.

해결법

1. ==============================

   1.하나의 가능한 유즈 케이스는 게으른 초기화 (종종 사용되지 않는 경우 처음 사용할 때 일부 필드 값을 계산) 또는 "레지스트리"와 같은 "일반적인"가변 단일 객체입니다.

   하나의 가능한 유즈 케이스는 게으른 초기화 (종종 사용되지 않는 경우 처음 사용할 때 일부 필드 값을 계산) 또는 "레지스트리"와 같은 "일반적인"가변 단일 객체입니다.

   그러나 대부분의 경우 열거 형 객체는 변경 가능하지 않아야하며 필드는 최종적이어야합니다.

2. ==============================

   2.흥미로운 사실을 여기서 지적하고있는 한, 내가 염려하는 한 변경 가능한 enum 필드에 대한 유스 케이스는 없다. 이 언어 "기능"( "버그"?)을 사용하는 것이 나쁜 생각 일 수밖에없는 많은 이유가 있습니다. 특히 다른 개발자를 혼란스럽게 할 가능성이 있습니다.

   흥미로운 사실을 여기서 지적하고있는 한, 내가 염려하는 한 변경 가능한 enum 필드에 대한 유스 케이스는 없다. 이 언어 "기능"( "버그"?)을 사용하는 것이 나쁜 생각 일 수밖에없는 많은 이유가 있습니다. 특히 다른 개발자를 혼란스럽게 할 가능성이 있습니다.

3. ==============================

   3.Alex D의 대답과 코멘트에 대한 응답으로 가능한 유스 케이스 게시에 대한 제안을하고 있습니다. 중력 등을 계산할 수있는 행성의 오래된 표준 enum 예제를 살펴 보겠습니다. 각 행성에서 인간 식민지의 수를 유지하고 싶다고 상상해보십시오. 예, EnumMap을 사용할 수는 있지만 더 많은 변경 가능한 필드가 필요할 수 있고 각 값에 대한 별도의지도 또는 열거 형과 관련된 변경 가능한 값을 보유하기위한 별도의 클래스가있는 경우를 직관적으로 볼 수 있습니다.

   Alex D의 대답과 코멘트에 대한 응답으로 가능한 유스 케이스 게시에 대한 제안을하고 있습니다. 중력 등을 계산할 수있는 행성의 오래된 표준 enum 예제를 살펴 보겠습니다. 각 행성에서 인간 식민지의 수를 유지하고 싶다고 상상해보십시오. 예, EnumMap을 사용할 수는 있지만 더 많은 변경 가능한 필드가 필요할 수 있고 각 값에 대한 별도의지도 또는 열거 형과 관련된 변경 가능한 값을 보유하기위한 별도의 클래스가있는 경우를 직관적으로 볼 수 있습니다.

   내 의견에 언급했듯이 일반적으로 열거 형은 일반적으로 불변이라고 생각하지만 유스 케이스가 없다는 것은 너무 강력하다고 생각합니다.

4. ==============================

   4.열거 형에서 변경 가능한 필드를 사용하는 것을 금지 할 이유는 없습니다. 유형의 값이 유한 (알려진) 가능성 집합 중 하나에 속한다고 명시하기 위해 열거 형을 사용합니다. 이러한 가치가 시간이지나면서 진화하는 속성을 가질 수 없다는 것을 의미하지는 않습니다.

   열거 형에서 변경 가능한 필드를 사용하는 것을 금지 할 이유는 없습니다. 유형의 값이 유한 (알려진) 가능성 집합 중 하나에 속한다고 명시하기 위해 열거 형을 사용합니다. 이러한 가치가 시간이지나면서 진화하는 속성을 가질 수 없다는 것을 의미하지는 않습니다.

   일부는 그러한 시나리오에 대한 유스 케이스를 요구했습니다. 예를 들어 ErrorCategory와 같은 열거 형을 사용하면 오류를 미리 정의 된 범주 수 (예 : DocumentationError, SemanticError, LayoutError ...) 중 하나로 분류 할 수 있습니다.

   이러한 ErrorCategories에 requiresInstantIntervention 또는 shouldFailBuild와 같은 속성이 있다고 가정합니다. 해당 속성의 값이 시간이지나면서 변경되거나 사용자가 구성 할 수 있다고 생각할 수 있습니다.

   나는 (실제로 위에서 언급 한 EnumMaps와 같은) 이것을 구현하는 많은 방법들이 있다는 것을 깨닫고 항상 스타일에 관해 논할 수 있지만, 저에게는 열거 형의 그러한 사용은 그 자체로 잘못된 것이 아닙니다. 열거 형은 java의 참조 유형이므로 ==의 동작은 처음에는 변경 가능한 속성이없는 경우와 동일하게 유지됩니다.

5. ==============================

   5.enum 인스턴스는 enum 클래스의 public static final Field입니다. 그래서 변경 가능하다면 다른 스레드에서 상태를 수정할 수 있습니다. 이것은 당신이 원한 것이 아니며 이것을 깨닫지 못하면 문제를 일으킬 수 있습니다.

   enum 인스턴스는 enum 클래스의 public static final Field입니다. 그래서 변경 가능하다면 다른 스레드에서 상태를 수정할 수 있습니다. 이것은 당신이 원한 것이 아니며 이것을 깨닫지 못하면 문제를 일으킬 수 있습니다.

6. ==============================

   6.사용 및 릴레이 할 때 보존하려는 컨트롤 외부에서 직렬화 된 숫자 값을 처리하기 위해 변경할 수있는 열거 형을 사용합니다. 예 :

   사용 및 릴레이 할 때 보존하려는 컨트롤 외부에서 직렬화 된 숫자 값을 처리하기 위해 변경할 수있는 열거 형을 사용합니다. 예 :

   VALUE_A = 1
   VALUE_B = 13
   VALUE_C = 17
   VALUE_UNRECOGNIZED
   

   예 : 일련 번호가 61 인 경우 어떻게됩니까? 나는 그것을 인식하지 못하기 때문에 그것에 대한 enum 상수가 없다. 그렇지 않으면 다루지 않는다. 그러나 나는 그것을 실패하고 싶지 않다 : 나는 연재 된 값을 보존하고 함께 전달하기를 원한다.

   아마도 표준 접근 방식은 불변의 enum과 원래 값이라는 두 개의 필드로 새로운 클래스를 만드는 것이지만, IMHO는 좀 더 성가시다.

7. ==============================

   7.내가 틀렸다면 정정하십시오. 그러나 열거 형은 Java에서 표준적인 정적 getInstance ()를 사용하는 것처럼 응용 프로그램의 수명 전체에 실제로 진정한 싱글 톤을 가질 수있는 가장 쉬운 방법입니다 (CDI를 사용할 수없는 경우). () 메소드 패턴은 너무 순진하게 구현되면 동일한 클래스의 여러 인스턴스를 생성 할 수 있습니다. 마찬가지로 Serializable을 구현하면 잠재적으로 하나 이상의 인스턴스를 생성 할 수 있지만 Enum은 예기치 않은 결과와 상용구없이 이미이를 처리합니다. 따라서 또한 Enum 형식은 단순한 상수 이상의 의미가 있다는 것을 문서에 분명하게 명시합니다. 그래서 나는 충분히 좋은 이유를 위해 애플 리케이션에 진정한 싱글 톤을 갖는 것이 절대적으로 필요하다고 생각할 때, 심지어 열거 형 (enum)도 정당한 사용으로 간주 될 수 있다고 말할 것이다. 그러나이 질문은 필연적으로 독창적 인 측면에서 약간의 경향이 있으며 불변 성을 선호하는 개발자가 있기 때문에 완전히 공평하지 않은 답변을 얻을 수 없다는 (그리고 나는 그것에 대한 좋은 이유가 없다고 말하지 않고있다) 개발자들도있다. 이 점에있어서 엄격하지 않고 기본 문서 기술은 코드 자체만큼 중요 할 수 있습니다 (enum 상수의 내부 상태가 실제로 javadoc에서 변경 가능하다는 사실을 강조하지 못하게하는 경우).

   내가 틀렸다면 정정하십시오. 그러나 열거 형은 Java에서 표준적인 정적 getInstance ()를 사용하는 것처럼 응용 프로그램의 수명 전체에 실제로 진정한 싱글 톤을 가질 수있는 가장 쉬운 방법입니다 (CDI를 사용할 수없는 경우). () 메소드 패턴은 너무 순진하게 구현되면 동일한 클래스의 여러 인스턴스를 생성 할 수 있습니다. 마찬가지로 Serializable을 구현하면 잠재적으로 하나 이상의 인스턴스를 생성 할 수 있지만 Enum은 예기치 않은 결과와 상용구없이 이미이를 처리합니다. 따라서 또한 Enum 형식은 단순한 상수 이상의 의미가 있다는 것을 문서에 분명하게 명시합니다. 그래서 나는 충분히 좋은 이유를 위해 애플 리케이션에 진정한 싱글 톤을 갖는 것이 절대적으로 필요하다고 생각할 때, 심지어 열거 형 (enum)도 정당한 사용으로 간주 될 수 있다고 말할 것이다. 그러나이 질문은 필연적으로 독창적 인 측면에서 약간의 경향이 있으며 불변 성을 선호하는 개발자가 있기 때문에 완전히 공평하지 않은 답변을 얻을 수 없다는 (그리고 나는 그것에 대한 좋은 이유가 없다고 말하지 않고있다) 개발자들도있다. 이 점에있어서 엄격하지 않고 기본 문서 기술은 코드 자체만큼 중요 할 수 있습니다 (enum 상수의 내부 상태가 실제로 javadoc에서 변경 가능하다는 사실을 강조하지 못하게하는 경우).

8. ==============================

   8.열거 형 상수 자체는 변경할 수 없으며 해당 필드는 변경할 수 있습니다.

   열거 형 상수 자체는 변경할 수 없으며 해당 필드는 변경할 수 있습니다.

from https://stackoverflow.com/questions/13015870/java-enums-mutability-usecases-and-possibilities by cc-by-sa and MIT license