Có ổn không khi đi ngược lại việc đặt tên cho tất cả các enum để làm cho biểu diễn Chuỗi của chúng đơn giản hơn?

Nhiều lần tôi đã thấy mọi người sử dụng trường hợp tiêu đề hoặc thậm chí tất cả các cách đặt tên chữ thường cho các hằng số enum, ví dụ:

enum Color {
  red,
  yellow,
  green;
}

Điều này làm cho việc làm việc với dạng chuỗi của họ trở nên đơn giản và dễ dàng, throw new IllegalStateException("Light should not be " + color + ".")ví dụ , nếu bạn muốn làm .

Điều này có vẻ dễ chấp nhận hơn nếu enum là vậy private, nhưng tôi vẫn không thích nó. Tôi biết tôi có thể tạo một hàm tạo enum bằng trường Chuỗi và sau đó ghi đè lênString để trả về tên đó, như sau:

enum Color {
  RED("red"),
  YELLOW("yellow"),
  GREEN("green");

  private final String name;

  private Color(String name) { 
    this.name = name 
  }

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

Nhưng nhìn nó dài hơn bao nhiêu Thật khó chịu khi tiếp tục làm nếu bạn có một bó nhỏ bạn muốn giữ đơn giản. Có ổn không khi chỉ sử dụng các định dạng trường hợp độc đáo ở đây?

Tất nhiên, câu trả lời ngắn gọn là liệu bạn có muốn phá vỡ các quy ước đặt tên cho các hằng số cơ bản không ... Trích dẫn từ JLS :

Tên không đổi

Tên của các hằng trong các loại giao diện nên và các biến cuối cùng của các loại lớp có thể theo quy ước là một chuỗi gồm một hoặc nhiều từ, từ viết tắt hoặc viết tắt, tất cả chữ hoa, với các thành phần được phân tách bằng ký tự "_" gạch dưới. Tên không đổi nên được mô tả và không được viết tắt không cần thiết. Thông thường họ có thể là bất kỳ phần thích hợp của bài phát biểu.

Câu trả lời dài, liên quan đến việc sử dụng toString(), đó chắc chắn là phương pháp để ghi đè nếu bạn muốn một đại diện dễ đọc hơn của các enumgiá trị. Trích dẫn từ Object.toString()(nhấn mạnh của tôi):

Trả về một chuỗi đại diện của các đối tượng. Nói chung, toStringphương thức trả về một chuỗi "đại diện bằng văn bản" đối tượng này . Kết quả phải là một đại diện ngắn gọn nhưng đầy đủ thông tin để người đó dễ đọc . Chúng tôi đề nghị rằng tất cả các lớp con ghi đè phương thức này.

Bây giờ, tôi không chắc tại sao một số câu trả lời lại chuyển sang nói về việc chuyển đổi enumsthành các Stringgiá trị, nhưng tôi cũng sẽ đưa ra ý kiến ​​của mình ở đây. Việc tuần tự hóa các enumgiá trị như vậy có thể dễ dàng được quan tâm bằng cách sử dụng name()hoặc ordinal()phương thức. Cả hai đều finalvà do đó bạn có thể chắc chắn về các giá trị được trả về miễn là tên hoặc định vị của các giá trị không thay đổi . Đối với tôi, đó là một điểm đánh dấu đủ rõ ràng.

Những gì tôi thu thập từ trên là: ngày nay, bạn có thể muốn mô tả YELLOWđơn giản là "màu vàng". Ngày mai, bạn có thể muốn mô tả nó là "Pantone Minion Yellow" . Những mô tả này nên được trả lại từ cuộc gọi toString()và tôi sẽ không mong đợi name()hoặc ordinal()thay đổi. Nếu tôi làm, đó là điều tôi cần giải quyết trong cơ sở mã của mình hoặc nhóm của tôi và trở thành một câu hỏi lớn hơn chỉ là một enumkiểu đặt tên .

Tóm lại, nếu tất cả những gì bạn định làm là ghi lại một đại diện dễ đọc hơn cho các enumgiá trị của bạn , tôi vẫn sẽ đề nghị tuân theo các quy ước và sau đó ghi đè toString(). Nếu bạn cũng có ý định tuần tự hóa chúng thành một tệp dữ liệu hoặc đến các đích không phải Java khác, bạn vẫn có các phương thức name()và ordinal()phương thức để sao lưu, do đó không cần phải lo lắng về việc ghi đè toString().

Đừng sửa đổi ENUMđó chỉ là mùi mã xấu. Đặt enum là enum và chuỗi là chuỗi.

Thay vào đó, sử dụng trình chuyển đổi CamelCase cho các giá trị chuỗi.

throw new IllegalStateException("Light should not be " + CamelCase(color) + ".");

Có nhiều thư viện mã nguồn mở đã giải quyết vấn đề này cho Java.

http://docs.guava-lologists.googlecode.com/git/javadoc/com/google/common/base/CaseFormat.html

Gửi enum giữa mã Java của tôi và cơ sở dữ liệu hoặc ứng dụng khách, tôi thường kết thúc việc đọc và viết các giá trị enum dưới dạng chuỗi. toString()được gọi ngầm khi nối chuỗi. Ghi đè toString () trên một số enum có nghĩa là đôi khi tôi chỉ có thể

"<input type='checkbox' value='" + MY_CONST1 + "'>"

và đôi khi tôi phải nhớ gọi

"<input type='checkbox' value='" + MY_CONST1.name() + "'>"

dẫn đến lỗi, vì vậy tôi không làm điều đó nữa. Trên thực tế, tôi không ghi đè bất kỳ phương thức nào trên Enum bởi vì nếu bạn ném chúng xung quanh để có đủ mã khách hàng, cuối cùng bạn sẽ phá vỡ sự mong đợi của ai đó.

Làm cho tên phương pháp mới của riêng mình, như public String text()hoặc toEnglish()hoặc bất cứ điều gì.

Đây là một chức năng trợ giúp nhỏ có thể giúp bạn tiết kiệm một số thao tác gõ nếu bạn có nhiều enum như trên:

public static String ucFirstLowerRest(String s) {
    if ( (s == null) || (s.length() < 1) ) {
        return s;
    } else if (s.length() == 1) {
        return s.toUpperCase();
    } else {
        return s.substring(0, 1).toUpperCase() + s.substring(1).toLowerCase();
    }
}

Thật dễ dàng để gọi .toUpperCase () hoặc .toLowerCase () nhưng việc lấy lại trường hợp hỗn hợp có thể khó khăn. Hãy xem xét màu sắc, "bleu de France." Pháp luôn được viết hoa, vì vậy bạn có thể muốn thêm phương thức textLower () vào enum của mình nếu bạn gặp phải điều đó. Khi bạn sử dụng văn bản này ở đầu câu, so với giữa câu, so với trong tiêu đề, bạn có thể thấy một toString()phương thức duy nhất sẽ bị thiếu. Và điều đó thậm chí không chạm vào các ký tự không hợp lệ trong các mã định danh Java hoặc gây khó chịu vì chúng không được thể hiện trên bàn phím tiêu chuẩn hoặc các ký tự không có vỏ (Kanji, v.v.).

enum Color {
  BLEU_DE_FRANCE {
    @Override public String textTc() { return "Bleu De France"; }
    @Override public String textLc() { return "bleu de France"; }
  }
  CAFE_NOIR {
    @Override public String textTc() { return "Café Noir"; }
  }
  RED,
  YELLOW,
  GREEN;

  // The text in title case
  private final String textTc;

  private Color() { 
    textTc = ucFirstLowerRest(this.toString());
  }

  // Title case
  public String textTc() { return textTc; }

  // For the middle of a sentence
  public String textLc() { return textTc().toLowerCase(); }

  // For the start of a sentence
  public String textUcFirst() {
    String lc = textLc();
    return lc.substring(0, 1).toUpperCase() + lc.substring(1);
  }
}

Không quá khó để sử dụng đúng cách:

IllegalStateException(color1.textUcFirst() + " clashes horribly with " +
                      color2.textLc() + "!")

Hy vọng rằng điều đó cũng chứng minh tại sao sử dụng các giá trị enum hỗn hợp cũng sẽ làm bạn thất vọng. Một lý do cuối cùng để giữ tất cả các mũ có hằng số enum bên dưới là làm như vậy tuân theo Nguyên tắc tối thiểu ngạc nhiên. Mọi người mong đợi nó, vì vậy nếu bạn làm điều gì đó khác biệt, bạn sẽ luôn phải tự giải thích hoặc xử lý những người lạm dụng mã của bạn.

Nếu có khả năng nhỏ nhất là các biểu diễn chuỗi này có thể được lưu trữ ở những nơi như cơ sở dữ liệu hoặc tệp văn bản, thì việc gắn chúng với các hằng số enum thực tế sẽ trở nên rất khó khăn nếu bạn cần phải cấu trúc lại enum của mình.

Điều gì sẽ xảy ra nếu một ngày bạn quyết định đổi tên Color.Whitethành Color.TitaniumWhitetrong khi có các tệp dữ liệu ngoài đó có chứa "Trắng"?

Ngoài ra, một khi bạn bắt đầu chuyển đổi các hằng số enum thành các chuỗi, bước tiếp theo tiếp theo sẽ là tạo các chuỗi cho người dùng thấy, và vấn đề ở đây là, như tôi chắc chắn rằng bạn đã biết, cú pháp của java không cho phép không gian trong định danh. (Bạn sẽ không bao giờ có Color.Titanium White.) Vì vậy, vì có thể bạn sẽ cần một cơ chế thích hợp để tạo tên enum để hiển thị cho người dùng, tốt nhất là tránh làm phức tạp hóa enum của bạn một cách không cần thiết.

Điều đó đã được nói, tất nhiên bạn có thể tiếp tục và làm những gì bạn đã nghĩ, và sau đó cấu trúc lại enum của bạn sau đó, để chuyển tên cho nhà xây dựng, khi nào (và nếu) bạn gặp rắc rối.

Bạn có thể loại bỏ một vài dòng khỏi enum-with-constructor của bạn bằng cách khai báo nametrường public finalvà mất getter. (Tình yêu mà các lập trình viên java dành cho getters là gì?)

Có thể cho rằng, theo quy ước đặt tên UPPERCASE vi phạm DRY . (Và YAGNI ). ví dụ, trong ví dụ mã số 2 của bạn: "ĐỎ" và "đỏ" được lặp lại.

Vì vậy, bạn làm theo quy ước chính thức hoặc theo DRY? Cuộc gọi của bạn.

Trong mã của tôi, tôi sẽ theo DRY. Tuy nhiên, tôi sẽ đưa ra một nhận xét về lớp Enum, nói rằng "không phải tất cả chữ hoa vì (giải thích ở đây)"