Dize temsillerini kolaylaştırmak için numaralandırmalar için tümüyle büyük harf adlandırmalarına karşı çıkmak uygun mudur?

Birkaç kez insanların enum sabitleri için başlık veya hatta tüm küçük harf adlandırma kullandığını gördüm, örneğin:

enum Color {
  red,
  yellow,
  green;
}

Bu, örneğin dize formlarıyla çalışmayı basit ve kolay hale getirir throw new IllegalStateException("Light should not be " + color + ".").

Enum ise bu daha kabul edilebilir görünüyor private, ama yine de hoşlanmıyorum. Ben bir dize alanı ile bir numaralandırma yapıcı yapabilir ve daha sonra bu gibi bu adı döndürmek için toString geçersiz kılabilir biliyorum:

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; 
  }
}

Ama ne kadar uzun olduğuna bakın. Basit tutmak istediğiniz küçük küçük numaralarınız varsa yapmaya devam etmek sinir bozucu. Burada alışılmadık vaka formatlarını kullanmak uygun mudur?

Kısa cevap sizden aktaran ... esasen sabitlerdir ne için adlandırma ile kırmak isteyip, tabii ki JLS :

Sabit İsimler

Arabirim türlerindeki sabitlerin adları olmalıdır ve sınıf türlerinin son değişkenleri geleneksel olarak, alt çizgi "_" karakterleri ile ayrılmış bileşenlerle birlikte bir veya daha fazla kelime, kısaltma veya kısaltmadan oluşan bir dizi olabilir. Sabit isimler açıklayıcı olmalı ve gereksiz yere kısaltılmamalıdır. Geleneksel olarak konuşmanın uygun herhangi bir parçası olabilirler.

Uzun cevap, kullanımı ile ilgili olarak , değerlerin toString()daha okunabilir bir temsilini istiyorsanız kesinlikle geçersiz kılma yöntemidir enum. Alıntı yapan Object.toString()(benim vurgu):

Nesnenin dize olarak temsilini döndürür. Genel olarak, toStringyöntem bu nesneyi "metinsel olarak" temsil eden bir dize döndürür . Sonuç, bir kişinin okuması kolay, kısa ama bilgilendirici bir temsil olmalıdır . Tüm alt sınıfların bu yöntemi geçersiz kılması önerilir.

Şimdi, bazı cevapların neden değerlerle enumsileri geri dönüş hakkında konuşmaya sürüklendiğinden emin değilim String, ama burada da benim yerimi alacağım. enumDeğerlerin bu şekilde serileştirilmesi , name()veya ordinal()yöntemleri kullanılarak kolayca halledilebilir . Her ikisi de vardır finalve bu nedenle değerlerin adları veya konumları değişmediği sürece döndürülen değerlerden emin olabilirsiniz . Bana göre, bu yeterince açık bir işaret.

Yukarıdakilerden topladığım şey: bugün, YELLOWsadece "sarı" olarak tanımlamak isteyebilirsiniz . Yarın, "Pantone Minion Yellow" olarak tanımlamak isteyebilirsiniz . Bu açıklamalar çağrıdan döndürülmeli toString()ve ben de ya name()da ordinal()değişmeyi beklemem . Bunu yaparsam, kod tabanımda veya ekibimde çözmem gereken bir şeydir ve sadece bir enumadlandırma stilinden daha büyük bir soru haline gelir .

Sonuç olarak, tek yapmanız gereken değerlerinizin daha okunabilir bir temsilini kaydetmekse enum, yine de kurallara bağlı kalmanızı ve ardından geçersiz kılmanızı öneririm toString(). Bunları bir veri dosyasına veya diğer Java dışı hedeflere serileştirmek istiyorsanız, yine de sizi yedeklemek için name()ve ordinal()yöntemleriniz vardır, bu nedenle geçersiz kılma konusunda endişelenmenize gerek yoktur toString().

Bu ENUMsadece kötü kod kokusu değiştirmeyin. Bir enum bir enum ve bir dize bir dize olsun.

Bunun yerine, dize değerleri için bir CamelCase dönüştürücü kullanın.

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

Java için bu sorunu zaten çözen birçok açık kaynak kitaplığı vardır.

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

Java kodum ile bir veritabanı veya istemci uygulaması arasında numaralandırma gönderirken, genellikle numaralandırma değerlerini okuma ve dizgiler olarak yazma. toString()dizeleri birleştirirken örtük olarak çağrılır. Bazı numaralarda toString () geçersiz kılmak, bazen sadece

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

ve bazen aramayı hatırlamak zorunda kaldım

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

bu da hatalara yol açtı, bu yüzden artık bunu yapmıyorum. Aslında, Enum'da herhangi bir yöntemi geçersiz kılmam çünkü onları yeterli müşteri koduna atarsanız, sonunda birinin beklentilerini kıracaksınız.

Kendi yönteminizin adını public String text()veya benzeri toEnglish()herhangi bir şeyi yapın.

Yukarıdaki gibi çok sayıda numaralandırma varsa size bazı yazmayı kurtarabilecek küçük bir yardımcı işlev:

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();
    }
}

.ToUpperCase () veya .toLowerCase () öğesini çağırmak her zaman kolaydır, ancak karışık durumu geri almak zor olabilir. "Bleu de France" rengini düşünün. Fransa her zaman büyük harfle yazılır, bu nedenle numaralandırmanızda numaralandırmanıza bir textLower () yöntemi eklemek isteyebilirsiniz. Bu metni bir cümlenin başında, bir cümlenin ortasına veya bir başlığa kullandığınızda, tek bir toString()yöntemin nasıl kısa süreceğini görebilirsiniz. Ve bu, Java tanımlayıcılarında yasadışı olan veya yazılması zor olan karakterlere, standart klavyelerde temsil edilmediğinden veya büyük / küçük harf içermeyen karakterlere (Kanji, vb.) Bile dokunmaz.

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);
  }
}

Bunları düzgün kullanmak çok zor değil:

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

Umarım bu da karışık vaka enum değerlerinin kullanılmasının neden sizi hayal kırıklığına uğratacağını gösterir. Alt çizgileri saymak sabitleri ile tüm kapaklar tutmak için son bir nedeni, bunu En Az Şaşkınlık Prensibi takip olmasıdır. İnsanlar bunu bekler, bu yüzden farklı bir şey yaparsanız, her zaman kendinizi açıklamak veya kodunuzu kötüye kullanan insanlarla uğraşmak zorunda kalacaksınız.

Bu dize temsillerinin veritabanları veya metin dosyaları gibi yerlerde saklanma şansı en düşükse, enum sabitlemelerinize bağlı olmaları, enumunuzu yeniden düzenlemeniz gerekirse çok sorunlu olacaktır.

Ya Yeniden adlandırmak karar bir gün Color.Whiteiçin Color.TitaniumWhiteveri "Beyaz" içeren orada dosyalar varken?

Ayrıca, enum sabitlerini dizelere dönüştürmeye başladığınızda, bir sonraki adım, kullanıcının görmesi için dizeler oluşturmak olacaktır ve burada sorun, bildiğiniz gibi, java sözdiziminin tanımlayıcılar içindeki boşluklara izin ver. (Asla sahip olamayacaksınız Color.Titanium White.) Yani, kullanıcıya göstermek için numaralandırma adları oluşturmak için muhtemelen uygun bir mekanizmaya ihtiyacınız olacağından, enumunuzu gereksiz yere karmaşıklaştırmaktan kaçınmak en iyisidir.

Bunu söyledikten sonra, elbette devam edip ne yapmayı düşündüğünüzü yapabilir ve daha sonra numaralandırmayı daha sonra, sorun yaşarsanız (ve eğer), kurucuya isimleri aktarmak için yeniden düzenleyebilirsiniz.

nameAlanı ilan public finaledip alıcıyı kaybederek, numaralandırıcı-kurucu ile birkaç çizgiyi tıraş edebilirsiniz . (Java programcılarının alıcılara karşı duyduğu bu aşk nedir?)

Tartışmalı olarak, UPPERCASE adlandırma kuralını izleyerek KURU ihlal edilir . (Ve YAGNI ). örneğin, kod örneğinizde # 2: "KIRMIZI" ve "kırmızı" tekrarlanır.

Peki, resmi sözleşmeyi mi takip ediyorsunuz yoksa DRY'yi mi takip ediyorsunuz? Çağrınız.

Kodumda, DRY'yi takip edeceğim. Ancak, Enum sınıfına "hepsi büyük harf değil çünkü (burada açıklama)" diyerek bir yorum yapacağım