Java numaralandırma üyelerini karşılaştırma: == veya eşittir ()?


1736

Java enums özel kurucuları ve bir grup kamu statik üyeleri ile sınıflara derlendi biliyorum. Belirli bir numaralandırmanın iki üyesini karşılaştırırken, her zaman kullandım .equals(), örn.

public useEnums(SomeEnum a)
{
    if(a.equals(SomeEnum.SOME_ENUM_VALUE))
    {
        ...
    }
    ...
}

Ancak, sadece ==.equals () yerine eşittir operatörünü kullanan bazı kod rastladım :

public useEnums2(SomeEnum a)
{
    if(a == SomeEnum.SOME_ENUM_VALUE)
    {
        ...
    }
    ...
}

Hangi operatörü kullanmalıyım?


7
Çok benzer bir soruya rastladım: stackoverflow.com/questions/533922/…
Matt Ball

39
Tüm cevaplarda (özellikle neden == çalıştığını ayrıntılı olarak açıklayan poligenelubrikantlardan) == başka bir büyük faydasının belirtilmediğine şaşırdım: numaraların nasıl çalıştığını (sabit bir singleton seti olarak) ) nesneleri. Eşittir, bir şekilde aynı enum 'alternatif'in etrafında yüzen birden fazla örneğinin olabileceğini düşünmeye yol açar.
Stuart Rossiter

6
Basit tutun. "==" daha okunabilir ve varsayılan olarak numaralandırmalar tekil olduğu için çalışır. Ref
lokesh

Yanıtlar:


1576

Her ikisi de teknik olarak doğrudur. Eğer kaynak koduna bakarsanız, .equals()basitçe onu korur ==.

Kullandığım ==şeklindeki sıfır güvenli olacak şekilde, ancak,.


64
Şahsen ben == kullanmak için bir neden olarak belirtilen 'null güvenlik' sevmiyorum.
Nivas

257
@Nivas: neden olmasın? Argümanlarınızın sırası hakkında endişelenmeyi seviyor musunuz (Pascal'ın cevabındaki gibi yalnızca soldaki sabitleri karşılaştırmak için geçerlidir)? Her zaman bir değerin girilmeden önce boş olup olmadığını kontrol etmeyi sever misiniz .equals()? Yapmadığımı biliyorum.
Matt Ball

86
Kodunuzu okurken, "==" okuyup gidip ilgili türün kaynağına bakana kadar okuyucu için yanlış görünebileceğini, ardından bunun bir enum olduğunu göreceğini unutmayın. Bu anlamda ".equals ()" okumak daha az dikkat dağıtıcıdır.
Kevin Bourrillion

60
@Kevin - kaynağı görüntülerken türleri doğrudan görmenizi sağlayan bir IDE kullanmıyorsanız, kendinizi aldatırsınız - uygun bir IDE ile ilgili bir sorun değil.
MetroidFan2002

63
Bazen kod yeniden düzenlenir ve bir enum'un bir sınıfla değiştirilmesi mümkündür; bu noktada == 'nin artık doğru olacağı garanti edilmezken, eşittir kesintisiz olarak çalışmaya devam eder. Bu nedenle, eşittir açıkça daha iyi bir seçimdir. Null güvenlik istiyorsanız (null kullanımını en aza indirecek şekilde yazılmamış bir kod tabanı üzerinde çalıştığınız için), Apache ObjectUtils veya Guava Nesneleri # eşittir (veya kendinizinkini yuvarlayabilirsiniz). Birisinin beni haklı bir Donald Knuth kitabıyla tokatladığını düşündüğüm için "performans" kelimesinden bile bahsetmeyeceğim.
laszlok

1113

Üzerinde ==kullanılabilir enummi?

Evet: numaralandırmalarda örnekleri ==karşılaştırmak için kullanabileceğiniz sıkı örnek denetimleri bulunur . Dil şartnamesi tarafından sağlanan garanti (benim tarafımdan vurgu):

JLS 8.9 Numaralandırmalar

Bir enum türünün, enum sabitleri tarafından tanımlananlardan başka bir örneği yoktur.

Bir numaralandırma türünü açıkça başlatmaya çalışmak derleme zamanı hatasıdır. final cloneYöntem Enumsağlar enumsabitler klonlanmış asla ve yinelenen örneklerini seriyi kaldırma sonucunda oluşturulan asla emin serileştirme mekanizması teminat altın ile özel muamele yok. Enum tiplerinin yansıtıcı örneklenmesi yasaktır. Birlikte, bu dört şey enum, enumsabitler tarafından tanımlanan türlerin ötesinde bir tür örneğin bulunmamasını sağlar .

Her enumsabitin yalnızca bir örneği bulunduğundan , en az birinin bir sabiti ifade ettiği biliniyorsa, iki nesne referansını karşılaştırırken operatörün yöntem yerine kullanılmasına izin verilir==equalsenum . ( equalsYöntem Enuma, finalbu sadece çağırır yöntem super.equals, böylece bir kimlik karşılaştırma yapmak argüman ve fayda sonucu, ilgili).

Bu garanti, Josh Bloch'un önerdiği kadar güçlüdür, eğer tekli kalıbı kullanmakta ısrar ediyorsanız, bunu uygulamanın en iyi yolu tek bir eleman kullanmaktır enum(bakınız: Etkili Java 2. Baskı, Madde 3: Tekton özelliğini bir özel kurucu veya enum tipi ; ayrıca Singleton'da iş parçacığı güvenliği )


Arasındaki farklar nelerdir ==ve equals?

Bir hatırlatma olarak, genel olarak, ==geçerli bir alternatif OLMADIĞI söylenmelidir equals. Bununla birlikte (olduğu gibi enum) dikkate alınacak iki önemli fark vardır:

== asla atmaz NullPointerException

enum Color { BLACK, WHITE };

Color nothing = null;
if (nothing == Color.BLACK);      // runs fine
if (nothing.equals(Color.BLACK)); // throws NullPointerException

== derleme zamanında tür uyumluluk denetimine tabidir

enum Color { BLACK, WHITE };
enum Chiral { LEFT, RIGHT };

if (Color.BLACK.equals(Chiral.LEFT)); // compiles fine
if (Color.BLACK == Chiral.LEFT);      // DOESN'T COMPILE!!! Incompatible types!

Should ==zaman uygulanabilir kullanılacak?

Bloch özellikle, örnekleri üzerinde uygun kontrole sahip olan değişmez sınıfların, müşterilerinin ==kullanılabilir olduğunu garanti edebileceğinden bahseder . enumörnek olarak özellikle belirtilmiştir.

Madde 1: Yapıcılar yerine statik fabrika yöntemlerini göz önünde bulundurun

[...] değişmez bir sınıfın iki eşit örneğin bulunmadığının garantisini vermesine izin verir: a.equals(b)eğer ve sadece a==b. Bir sınıf bu garantiyi verirse, müşterileri yöntem ==yerine operatörü kullanabilir ve equals(Object)bu da performansın artmasına neden olabilir. Enum tipleri bu garantiyi sağlar.

Özetlemek gerekirse, ==üzerinde kullanılacak argümanlar enumşunlardır:

  • İşe yarıyor.
  • O daha hızlı.
  • Çalışma zamanında daha güvenlidir.
  • Derleme zamanında daha güvenlidir.

27
Güzel cevap ama ... 1. Çalışıyor : kararlaştırıldı 2. daha hızlı : numaralandırmalar için kanıtlayın :) 3. Çalışma zamanında daha güvenlidir : Color nothing = null;IMHO bir hatadır ve düzeltilmelidir, sayımınızın üç değil iki değeri vardır ( Tom Hawtin'in yorumuna bakın) 4. Derleme zamanında daha güvenli : Tamam, ama equalsyine de dönecekti false. Sonunda, ben tercih ederim, bunu almayın equals()(Kevin'in yorumunu bakınız) okunabilirlik için.
Pascal Thivent

201
Bazı insanlara göre foo.equals(bar)daha okunabilir olduğunu düşündükleri Java'ya karşı kara bir izfoo == bar
Bennett McElwee

19
İşe yarıyor: Bir enumu yeniden düzenleme işleminin bir parçası olarak bir sınıfla değiştirmeniz gerekene kadar. == kullanarak tüm kodu bulmak iyi şanslar. Daha hızlı: Doğru olsa bile (şüpheli), erken optimizasyon hakkında Knuth alıntısı var. Çalışma zamanında daha güvenli: "Güvenli", == kullanımı sizi bir NullPointerException öğesinden ayıran tek şeyse akla ilk gelen sözcük değildir. Derleme zamanında daha güvenli: Pek değil. Sizi yanlış türleri karşılaştırmanın oldukça basit hatasından koruyabilir, ancak yine de, programcılarınız bu kadar aptalsa, "güvenli" olmadığınız tek şeydir.
laszlok

35
"programcılarınız bu kadar aptalsa," güvenli "olmadığınız tek şeydir." - Bu alıntıya katılmıyorum. Tip kontrolünün amacı budur: derleme zamanında "aptal" hataların önlenmesi, dolayısıyla kod çalıştırılmadan önce. Akıllı insanlar bile aptalca hatalar yapar, vaatlerden daha iyi garantiler verir.
ymajoros

7
@laszlok: tabii, ama işler başarısız olursa, sadece yapacaklar. Bazı aptal hatalar için bir çite sahip olmak her zaman iyi bir şeydir. Daha az önemsiz hatalar için yaratıcı olmak için bolca yer var, kodunuzu çalıştırmayı denemeden önce derleyicinin bunu kullanmasına izin verin.
ymajoros

88

==İki numaralandırma değerini karşılaştırmak için kullanılır , çünkü her numaralandırma sabiti için yalnızca bir nesne vardır.

Bir yan notta, ==eğer böyle yazıyorsanız, null-güvenli kod yazmak için kullanmaya gerek yoktur equals():

public useEnums(final SomeEnum a) {
    if (SomeEnum.SOME_ENUM_VALUE.equals(a)) {
        
    }
    
}

Bu kesinlikle takip etmeniz gereken Soldan Sabitleri Karşılaştır olarak bilinen en iyi uygulamadır .


9
.equals()Dize değerleri ing yaparken bunu yapıyorum , ama yine de null-güvenli kod yazmak için berbat bir yol olduğunu düşünüyorum. Ben çok bir işleç (veya bir yöntem var, ama biliyorum [boş nesne] .equals her zaman null-güvenli, ne olursa olsun her zaman null-güvenli, Java hiçbir zaman null güvenli olmayacak biliyorum Anlamsal olarak, "eşittir" operatörü her zaman işe gidip gelmelidir .
Matt Ball

2
Java, Groovy ( ?.) Güvenli Gezinme operatörüne sahip olmadığından, sabitleri karşılaştırırken bu uygulamayı kullanmaya devam edeceğim ve TBH, boktan bulmuyorum, belki sadece daha az "doğal".
Pascal Thivent

32
Bir nullnumaralandırma genellikle bir hatadır. Tüm olası değerlerin bu numaralandırmasına sahipsiniz ve işte bir tane daha!
Tom Hawtin - tackline

8
Açık bir şekilde ek açıklamalı değerler dışında @Nullable, Soldaki Sabitleri Karşılaştır'ı bir karşıtlık olarak görüyorum, çünkü hangi değerlerin boş olabileceği veya boşaltılamayacağı konusundaki belirsizliği yayar. Enum türleri neredeyse hiç olmamalıdır @Nullable, bu nedenle boş değer bir programlama hatası olur; böyle bir durumda, NPE'yi ne kadar erken atarsanız, programlama hatasını boşuna izin verdiğiniz yerde bulma olasılığınız o kadar artar. Enum türleri söz konusu olduğunda "kesinlikle takip etmeniz gereken en iyi uygulama" oldukça yanlıştır.
Tobias

24
Soldan Sabitler karşılaştırın Yoda tarzı en iyi İngilizce gibi en iyi uygulama.
maaartinus

58

Diğerlerinin söylediği gibi, her ikisi de ==ve .equals()çoğu durumda çalışır. Diğerlerinin işaret ettiği tamamen farklı Nesne türlerini karşılaştırmayacağınız derleme zamanı kesinliği geçerli ve yararlıdır, ancak iki farklı derleme zamanı türündeki nesneleri karşılaştırmadaki belirli bir hata da FindBugs tarafından bulunur (ve muhtemelen Eclipse / IntelliJ zaman denetimlerini derler), böylece Java derleyicisi onu bu kadar fazla güvenlik sağlamaz.

Ancak:

  1. Aslında ==aklımda NPE atar asla değildir dezavantaj ait ==. İfade etmek isteyebileceğiniz herhangi bir ekstra durum, ek bir örnek olarak eklenebilir , çünkü enumtürlerin olmasına hiç gerek yoktur . Beklenmedik bir şekilde , sessizce yanlış olarak değerlendirmekten ziyade NPE'ye sahip olmayı tercih ederim . Bu yüzden çalışma zamanı görüşünde daha güvenli olduğuna katılmıyorum ; asla değerlere izin vermemek alışkanlığına girmek daha iyidir .nullnullenumnull==enum@Nullable
  2. Argüman ==olduğunu daha hızlı da sahte. Çoğu durumda .equals()derleme zamanı türü enum sınıfı olan bir değişkeni çağırırsınız ve bu durumlarda derleyici bununla aynı olduğunu bilir ==(çünkü bir enum' equals()yöntemi geçersiz kılınamaz) ve işlev çağrısını optimize edebilir uzakta. Derleyicinin şu anda bunu yapıp yapmadığından emin değilim, ancak bunu yapmazsa ve genel olarak Java'da bir performans sorunu olduğu ortaya çıkarsa, derleyiciyi 100.000 Java programcısının programlama stilini uygun şekilde değiştirmesine göre düzeltmeyi tercih ederim belirli bir derleyici sürümünün performans özellikleri.
  3. enumsnesnelerdir. Diğer tüm Nesne türleri için standart karşılaştırma .equals()değildir ==. İstisna yapmak tehlikeli olduğunu düşünüyorum, enumsçünkü özellikle bir numarasız sınıfa yeniden odaklanırsanız, Nesneleri yanlışlıkla ==yerine karşılaştırabilirsiniz . Böyle bir yeniden düzenleme durumunda, yukarıdan çalışır noktası yanlıştır. Kullanımının doğru olduğuna kendinizi ikna etmek için, söz konusu değerin bir ilkel mi yoksa ilkel mi olduğunu kontrol etmeniz gerekir ; eğer bir sınıf olmasaydı, kod derleneceğinden yanlış ama kaçırması kolay olurdu. Tek kullanımlıkequals()enum==enumenum.equals()söz konusu değerlerin ilkel olması yanlış olur; bu durumda, kod derlenmez, bu yüzden kaçırmak çok daha zordur. Bu nedenle, .equals()doğru olarak tanımlanması çok daha kolaydır ve gelecekteki yeniden düzenlemelere karşı daha güvenlidir.

Aslında Java dilinin sol el değerinde .equals () çağırmak ve nesne kimliği için ayrı bir işleç tanıtmak için Nesneler üzerinde == tanımlanmış olması gerektiğini düşünüyorum, ancak Java bu şekilde tanımlanmadı.

Özetle, hala argümanların tipler .equals()için kullanılmasını desteklediğini düşünüyorum enum.


4
3. noktaya gelince, biraz özel olmaları için hedef enumolarak kullanabilirim switch. Strings de biraz özel.
CurtainDog

Anahtar ifadelerinin sözdizimi ne == ne de .equals () içerir, bu yüzden ne demek istediğini göremiyorum. Benim amacım 3.) bir okuyucunun doğrulanmasının ne kadar kolay olduğudur. Switch deyimlerinin derleme olduğu sürece switch deyimlerinin eşitlik semantiği doğrudur.
Tobias

17

Şunun ==yerine kullanmayı tercih ederim equals:

Başka bir neden, burada daha önce tartışılanlara ek olarak, farkında olmadan bir hata getirebilmenizdir. Diyelim ki tamamen aynı ama ayrılmış pacaklarda bu sıralamalar var (yaygın değil, ama olabilir):

İlk numaralandırma :

package first.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

İkinci numaralandırma:

package second.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Sonra bir sonraki gibi eşittir kullandığınızı item.category, first.pckg.Categoryancak second.pckg.Categoryfarkında olmadan ilk yerine ikinci numarayı ( ) içe aktardığınızı varsayın :

import second.pckg.Category;
...

Category.JAZZ.equals(item.getCategory())

Eğer daima alacak Yani falsesen gerçek çünkü beklemek rağmen farklı bir numaralandırma nedeni item.getCategory()olduğunu JAZZ. Ve görmek biraz zor olabilir.

Bu nedenle, operatörü kullanırsanız ==bir derleme hatası alırsınız:

operator == "second.pckg.Category", "first.pckg.Category" 'ye uygulanamaz

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Bahsettiğiniz çok iyi noktalar. Yani ne yapacağım myenum.value () applay ve sonra == karşılaştırma NPE güvenliği için.
Java Main

14

İşte ikisini karşılaştırmak için kaba bir zamanlama testi:

import java.util.Date;

public class EnumCompareSpeedTest {

    static enum TestEnum {ONE, TWO, THREE }

    public static void main(String [] args) {

        Date before = new Date();
        int c = 0;

        for(int y=0;y<5;++y) {
            for(int x=0;x<Integer.MAX_VALUE;++x) {
                if(TestEnum.ONE.equals(TestEnum.TWO)) {++c;}
                if(TestEnum.ONE == TestEnum.TWO){++c;}              
            }
        }

        System.out.println(new Date().getTime() - before.getTime());
    }   

}

IF'leri birer birer yorumlayın. Demonte bayt kodunda yukarıdaki iki karşılaştırma:

 21  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 24  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 27  invokevirtual EnumCompareSpeedTest$TestEnum.equals(java.lang.Object) : boolean [28]
 30  ifeq 36

 36  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 39  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 42  if_acmpne 48

Birincisi (eşittir) sanal bir çağrı yapar ve yığından boole dönüşünü test eder. İkinci (==) nesne adreslerini doğrudan yığından karşılaştırır. İlk durumda daha fazla aktivite var.

Bu testi her iki IF ile aynı anda birkaç kez çalıştırdım. "==" hiç bu kadar hızlı olmamıştı.


Derleyici dal tahmininin bu testi geçersiz kılabileceğinden şüpheleniyorum. Akıllı bir derleyici, ifadelerin her zaman yanlış olarak değerlendirileceğini ve böylece birden fazla karşılaştırma yapmaktan kaçınacağını fark eder. Gerçekten akıllı bir derleyici, y ve x döngülerindeki değerlerin sonuç üzerinde hiçbir etkisi olmayacağını ve her şeyi optimize edeceğini bile fark edebilir ...
Darrel Hoffman

Olabilir, ama kesinlikle değil. Cevabımda derleyici tarafından üretilen gerçek bayt kodunu gösteriyorum.
ChrisCantrell

ikiniz de kafanız karıştı. :-) Şube tahmini çalışma zamanında çalışır, bu nedenle farklı bayt kodu süper alakalı değildir. Ancak, bu durumda şube tahmini her iki duruma da eşit olarak yardımcı olacaktır .
vidstige

7
Kimin umrunda? Bir video oyunu sırasında bir döngü içinde binlerce kez enums karşılaştırmak sürece ekstra nanosaniye anlamsız.
user949300

Yorumlanmış modu zorlamadığınız sürece bayt kodu performansla ilgisizdir. Performansın tamamen aynı olduğunu görmek için bir JMH karşılaştırması yazın .
maaartinus


7

tl; Dr.

Başka bir seçenek Objects.equalsyardımcı yöntemdir.

Objects.equals( thisEnum , thatEnum )

Objects.equals sıfır güvenlik için

.equals () yerine operatör == eşittir

Hangi operatörü kullanmalıyım?

Üçüncü seçenek, Java 7 ve sonraki sürümlerine eklenen yardımcı program sınıfında equalsbulunan statik yöntemdir .Objects

Misal

İşte Monthenum'u kullanan bir örnek .

boolean areEqual = Objects.equals( Month.FEBRUARY , Month.JUNE ) ;  // Returns `false`.

Yararları

Bu yöntemin birkaç faydasını görüyorum:

  • Boş güvenliği
  • Kompakt, okunabilir

Nasıl çalışır

Mantık ne tarafından kullanılır Objects.equals?

Dan, kendiniz görün Java 10 kaynak kodu arasında OpenJDK :

return (a == b) || (a != null && a.equals(b));

6

==Enum sabitlerini karşılaştırmaktan başka bir şey kullanmak saçmalıktır. Nesneleri karşılaştırmakclassequals gibidir - yapma!

Ancak, Sun JDK 6u10 ve önceki sürümlerinde tarihi nedenlerden dolayı ilginç olabilecek kötü bir hata (BugId 6277781 ) vardı. Bu hata ==, tartışmalı bir şekilde bir köşe vakası olmasına rağmen, serileştirilmiş numaraların doğru kullanımını önledi .


4

Numaralandırmalar public static final field(değişmez) tarafından bildirilen her numaralandırma sabiti için bir örnek (tektonlar gibi) döndüren sınıflardır, böylece ==operatör equals()yöntemi kullanmak yerine eşitliklerini kontrol etmek için kullanılabilir


1

Numaraların == ile kolayca çalışmasının nedeni, tanımlanan her örneğin aynı zamanda tek bir ton olmasıdır. Yani == kullanarak kimlik karşılaştırması her zaman işe yarayacaktır.

Ancak == kullanmak, numaralandırmalarla çalıştığı için, tüm kodunuzun bu numaralandırma kullanımı ile sıkıca bağlandığı anlamına gelir.

Örneğin: Numaralandırmalar bir arabirim uygulayabilir. Şu anda Interface1'i uygulayan bir enum kullandığınızı varsayalım. Daha sonra birisi değiştirirse veya aynı arabirimin uygulanması olarak yeni bir sınıf Impl1 ekler. Sonra, Impl1 örneklerini kullanmaya başlarsanız, önceki == kullanımı nedeniyle değiştirmek ve test etmek için çok fazla kodunuz olacaktır.

Bu nedenle, haklı bir kazanç olmadıkça iyi bir uygulama olarak kabul edilen şeyleri takip etmek en iyisidir.


Güzel cevap, ama burada zaten bahsedildi .
shmosel

Um. Bu noktada soru, bir arayüzde == veya eşittir kullanıp kullanmayacağınızla ilgili olacaktır. Ayrıca, değişmez tipte bir uygulamanın yerine değişebilir bir uygulamanın yerini almanın gerçekten mantıklı olup olmadığı hakkında her türlü soru. Ve haklı kazanç konusunda endişelenmeden önce muhtemelen iyi uygulamanın ne olduğunu bulmak akıllıca olacaktır. (imho == daha iyi bir uygulamadır).
Robin Davies

1

Sonar kurallarından biri Enum values should be compared with "==". Şöyle nedenleri vardır:

Bir enum değerinin eşitliğini sınamak equals()mükemmel bir şekilde geçerlidir, çünkü bir enum bir Nesnedir ve her Java geliştiricisi ==bir Nesnenin içeriğini karşılaştırmak için kullanılmamalıdır. Aynı zamanda, ==numaralandırmalarda kullanarak :

  • ile aynı beklenen karşılaştırmayı (içerik) sağlar equals()

  • daha güvenli equals()

  • çalışma zamanı denetimi yerine derleme zamanı (statik) denetimi sağlar

Bu nedenlerle, kullanımı ==tercih edilmelidir equals().

Son fakat en az değil, ==on enums tartışmaya göre daha okunaklı (daha az ayrıntılı) equals().


0

Kısacası, her ikisinin de artıları ve eksileri vardır.

Bir yandan, ==diğer cevaplarda açıklandığı gibi, kullanım avantajları vardır .

Öte yandan, herhangi bir nedenden dolayı numaralandırmaları farklı bir yaklaşımla (normal sınıf örnekleri) değiştirirseniz, ==sizi ısırır. (BTDT.)


-1

Poligeno-yağlayıcıların cevabını tamamlamak istiyorum:

Şahsen eşittir (). Ama göl tip uyumluluk kontrolü. Bence bu önemli bir sınırlama.

Derleme zamanında tür uyumluluk denetimine sahip olmak için, numaralandırmanızda özel bir işlev bildirin ve kullanın.

public boolean isEquals(enumVariable) // compare constant from left
public static boolean areEqual(enumVariable, enumVariable2) // compare two variable

Bununla, her iki çözümün de tüm avantajlarına sahip olursunuz: NPE koruması, okunması kolay kod ve derleme zamanında tür uyumluluk denetimi.

Ayrıca numaralandırma için UNDEFINED değeri eklemenizi de öneririm.


4
Bu çözüm neden daha iyi ==? İle ==kolay okunur kod ve derleme zamanı tür uyumluluk denetimi NPE koruma, almak ve bunların hepsi olsun herhangi bir özel eşittir benzeri yöntemlerle yazmadan.
Matt Ball

1
Bir UNDEFINEDdeğer muhtemelen iyi bir fikirdir. Elbette, Java 8'de Optionalbunun yerine bir tane kullanırsınız.
Tomas

-7

==atabilir NullPointerExceptionilkel türü, Sınıf sürümüne göre olup olmadığını. Örneğin:

private static Integer getInteger() {
    return null;
}

private static void foo() {
    int a = 10;

    // Following comparison throws a NPE, it calls equals() on the 
    // non-primitive integer which is itself null. 
    if(a == getInteger()) { 
        // Some code
    }
}

2
Bu soruda kapsam oldukça açıktır ve ilkel türler kapsamda değildir.
Tom

@Tom burada devam eden tartışma ==asla atmayacak yanıltıcıdır NPEs. Bu sorunun yeterli cevabı var, ancak benim gibi hata / özellik almak için 2 saat süren birinin bunu okuması durumunda iyi bir referans olabilir.
ayushgp

1
Bu sorunun konusunu görmezden gelmediğinizde NPE atamıyorum. Ve bu yanıtı burada saklasanız bile, aynı sorunu yaşayan birinin bu cevabı farklı bir şey arayarak bulacağını düşünüyor musunuz? Bu kişinin kullanmadığı açık artırmaları araması gerekir. Bu yanıt bu soru için daha anlamlı olacaktır: stackoverflow.com/questions/7520432/…
Tom
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.