2012-10-22 37 views
8

Tôi không biết liệu tôi có phải là người duy nhất biết điều đó, nhưng các giá trị của một enum không hoàn toàn là cuối cùng và có thể được sửa đổi.Java enums khả năng đột biến usecases và khả năng?

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 

Những giá trị này được oftenly khởi tạo vào việc tạo ra dụ (TOTO("TOTO 1")) nhưng, ngoại trừ bản thân mình, tôi chưa bao giờ thấy bất cứ ai sử dụng từ khóa cuối cùng cho các biến enum mà nên thay đổi. Đó không phải là điểm của câu hỏi, chỉ cần tự hỏi nếu tôi là người duy nhất nhận thức được điều này.


Điều tôi muốn biết là có cách nào để tạo ra các enums có thể thay đổi không?

Và tôi cũng muốn biết giới hạn của những gì chúng ta có thể làm với enums (thực hành tốt hay không). Tôi đã không thử nghiệm nó, nhưng có lẽ một enum có thể được tiêm với đậu mùa xuân? Ít nhất có vẻ như chúng ta có thể chú thích từng cá thể (@Deprecated hoạt động tốt cho exemple), và cũng là phương pháp.

+7

Sử dụng 'cuối cùng' cho các trường là thực tế phổ biến trong enums. –

Trả lời

7

Một cách sử dụng có thể là khởi tạo lười (tính toán một số giá trị trường khi chúng được sử dụng lần đầu tiên, nếu thường chúng không được sử dụng) hoặc đối tượng đơn lẻ "bình thường" (như đăng ký hoặc như vậy).

Trong hầu hết các trường hợp, các đối tượng enum sẽ không thay đổi và trường của chúng là cuối cùng.

-3

Điều tôi muốn biết là liệu có bất kỳ ứng dụng nào để tạo ra các enums có thể thay đổi không?

Các hằng số enum không thể thay đổi được, trường của chúng có thể thay đổi.

+1

Đó là ý của anh ấy, như tôi đã hiểu. –

+0

Vâng đó là ý của tôi, nhưng việc sử dụng "chung" là tạo ra các enums bất biến, nhưng không ai sử dụng "final" –

+0

Đó là vì hiếm khi có 'enum' với trường' public' hoặc phương thức công khai để thay đổi trường IMHO . Nhưng tôi đồng ý rằng các trường sẽ được khai báo 'final'. –

6

Trong khi bạn chỉ ra một sự thật thú vị ở đây, theo như tôi quan tâm, không có trường hợp nào cho các trường enum có thể thay đổi được. Có nhiều lý do tại sao việc sử dụng ngôn ngữ này "tính năng" ("lỗi"?) Sẽ là một ý tưởng tồi, không ít trong số đó là khả năng gây nhầm lẫn cho các nhà phát triển khác.

+3

Tôi đồng ý rằng các enums thường được giả định là không thay đổi và do đó tạo ra các enums có thể biến đổi có thể dẫn đến lạm dụng. Tôi sẽ đề nghị rằng các giá trị có thể thay đổi liên kết với enums tốt nhất sẽ được giúp đỡ trong một 'EnumMap'. Điều đó nói rằng, tôi nghĩ rằng có "không có usecase" là quá mạnh. Enums trong thực tế đại diện cho một phần mở rộng của mô hình singlton (một số cố định của các trường hợp) và với ý nghĩ đó có thể được sử dụng như bất kỳ lớp nào khác. Tôi một lần nữa nhắc lại rằng các nhà phát triển MOST được sử dụng để suy nghĩ của họ như là IMMUTABLE và do đó enums mutable có thể dẫn đến vấn đề bảo trì. –

+0

Cảm ơn chúa vì chúng được cho là bất biến, nói chung là không có setter :) –

+0

@JohnB, nếu bạn có thể nghĩ ra một ví dụ điển hình về tình huống sử dụng enum với các trường có thể thay đổi được cho là tốt hơn so với bất kỳ phương án thay thế nào. một câu trả lời riêng. Nhưng câu trả lời của tôi vẫn là: theo như tôi đang quan tâm, có ** không có ** usecase, ít nhất không phải là một usecase mà không thể được phục vụ tốt hơn với một lớp 'bình thường'. Bạn đang đúng về những gì enums là "trong thực tế", nhưng khái niệm họ gần gũi hơn với một 'boolean' (trong đó có một tập hợp cố định của 2 giá trị có thể) hoặc một' int' (cố định thiết lập của 2^32-1 giá trị có thể) . Bạn có thể tưởng tượng có các trường có thể thay đổi trên 'true' không? –

3

Để trả lời câu trả lời và nhận xét của Alex D, tôi đang đưa ra đề xuất của ông về việc đăng một trường hợp sử dụng có thể. Chúng ta hãy lấy ví dụ enum chuẩn của các hành tinh mà từ đó trọng lực, vv có thể được tính toán. Hãy tưởng tượng rằng bạn muốn duy trì số lượng thuộc địa của con người trên mỗi hành tinh. Có, bạn có thể sử dụng một EnumMap, nhưng tôi có thể thấy một trường hợp ngày càng nhiều trường có thể thay đổi và có một bản đồ riêng biệt cho mỗi giá trị hoặc một lớp riêng biệt để giữ các giá trị có thể thay đổi được liên kết với một enum sẽ phản trực giác.

Như tôi đã nói trong nhận xét của mình, nói chung tôi tin rằng enums thường là và nên không thay đổi nhưng tôi cảm thấy rằng không có trường hợp sử dụng nào quá mạnh.

1

Tôi không thấy lý do nào để cấm sử dụng các trường có thể thay đổi trong enum s. Một sử dụng một enum để nói rằng giá trị của loại thuộc về một tập hợp các khả năng hữu hạn (và đã biết). Nó không ngụ ý rằng những giá trị đó không thể có các đặc tính phát triển theo thời gian.

Một số đã yêu cầu các trường hợp sử dụng cho trường hợp như vậy. Một ví dụ là sử dụng loại enum chẳng hạn như ErrorCategory, sẽ phân loại lỗi thành một trong số bất kỳ danh mục được xác định trước nào (ví dụ: DocumentationError, SemanticError, LayoutError ...).

Giả sử những người này ErrorCategories có các thuộc tính như requiresInstantIntervention hoặc shouldFailBuild. Tôi có thể tưởng tượng rằng giá trị của những thuộc tính đó có thể thay đổi theo thời gian hoặc chúng có thể được người dùng cấu hình.

Tôi nhận ra rằng có rất nhiều cách khác để thực hiện điều này (như thực tế là EnumMaps được đề cập ở trên) và một người luôn có thể tranh luận về phong cách, nhưng đối với tôi, việc sử dụng enum s không phải là sai. Như enum s là các loại tham chiếu trong java, hành vi của == vẫn giữ nguyên như thể không có thuộc tính có thể thay đổi ở vị trí đầu tiên.

0

Trường hợp enum là trường tĩnh cuối cùng công khai của lớp enum. Vì vậy, nếu nó có thể thay đổi, bạn có thể sửa đổi trạng thái của nó trong một chuỗi khác. Điều này có thể không phải là những gì bạn muốn và có thể gây ra vấn đề nếu bạn không nhận ra điều này.

Các vấn đề liên quan